Does anyone know how CMedia is treating CM6635? Is that something you can get firmware source for? The CM6631A is very old and the need for external flash and the power consumption aren't amazing.
Oh nice they've released some updated chips. CM6635 and CM6212. I personally prefer the look of the CM6212 for full multichannel support but the integrated flash memory makes things a lot more convenient.
Interestingly though if the CM6632A had its flash memory integrated I wouldn't have been able to do anything after I bricked the device with dodgy firmware. Hopefully the devices with integrated firmware come with a feature that gets around this issue.
The issue comes from the device being unrecognisable by windows once the faulty firmware has been uploaded. As a result the firmware updater doesn't work and you can't erase the firmware using it. I guess they'll have thought of this with the new chips, I hope so at least.
I didn't think that 100mA @5V for the 6632A was particularly high myself what do the XMOS parts run at?
I guess the one thing I am the most curious about is whether or not the integration of the memory onto the chip, and other improvements, will have reduced the random clock jitter present on the master clocks that the 31/32 devices put out. It occurred to me that this could be because of the added digital noise associated with all of the data/clock lines to and from the external flash memory.
You can apparently reduce the drive strength on the pins to the flash memory. I guess this could lower the noise by reducing slew rates although I've yet to try this. Another idea was to use a spread spectrum oscillator for the 12MHz clock. All in an attempt to reduce noise within the processing half of the chip but this gets routed through a PLL anyway before feeding the micro. Don't want to give the PLL a headache locking onto the source clock or if it works fine with a spread spectrum the PLL might just remain constant at 48MHz and filter out the spread!
One thing I am curious about though is USB4.0. This is dramatically different to current USB and gives rise to potential advantages in data transmission for upcoming audio chips. As far as I understand it can essentially function as a direct PCI-E lane if necessary and various other protocols including backwards compatibility with current USB. My hope is that it will completely do away with the limitations of current USB with regards to clock sources and drivers and such. A new USB4.0 audio specification is apparently going to be drawn up which would be great. Maybe we'll get companies like TI making generic USB4.0 audio chips that operate asynchronously as standard. Here's hoping! 😀
Interestingly though if the CM6632A had its flash memory integrated I wouldn't have been able to do anything after I bricked the device with dodgy firmware. Hopefully the devices with integrated firmware come with a feature that gets around this issue.
The issue comes from the device being unrecognisable by windows once the faulty firmware has been uploaded. As a result the firmware updater doesn't work and you can't erase the firmware using it. I guess they'll have thought of this with the new chips, I hope so at least.
I didn't think that 100mA @5V for the 6632A was particularly high myself what do the XMOS parts run at?
I guess the one thing I am the most curious about is whether or not the integration of the memory onto the chip, and other improvements, will have reduced the random clock jitter present on the master clocks that the 31/32 devices put out. It occurred to me that this could be because of the added digital noise associated with all of the data/clock lines to and from the external flash memory.
You can apparently reduce the drive strength on the pins to the flash memory. I guess this could lower the noise by reducing slew rates although I've yet to try this. Another idea was to use a spread spectrum oscillator for the 12MHz clock. All in an attempt to reduce noise within the processing half of the chip but this gets routed through a PLL anyway before feeding the micro. Don't want to give the PLL a headache locking onto the source clock or if it works fine with a spread spectrum the PLL might just remain constant at 48MHz and filter out the spread!
One thing I am curious about though is USB4.0. This is dramatically different to current USB and gives rise to potential advantages in data transmission for upcoming audio chips. As far as I understand it can essentially function as a direct PCI-E lane if necessary and various other protocols including backwards compatibility with current USB. My hope is that it will completely do away with the limitations of current USB with regards to clock sources and drivers and such. A new USB4.0 audio specification is apparently going to be drawn up which would be great. Maybe we'll get companies like TI making generic USB4.0 audio chips that operate asynchronously as standard. Here's hoping! 😀
Right but the other link has all the files you'll need except the firmware updater tool. I believe the tool is in one of the other links?
Hi, For all that are looking for the CM6631A firmware and firmware updater here they are. I had to use the help of the wayback machine to retrieve the firmware updater from a link that dated back to 2013.
CM6631A.zip - Google Drive
Also remember you need a physical WinXP machine not a VM or compatibility modes
CM6631A.zip - Google Drive
Also remember you need a physical WinXP machine not a VM or compatibility modes
I bought a Ciry Audio CM6631A, this one:
CM6631A DAC Board Digital interface card USB To IIS SPDIF Output 24Bit 192K New | eBay
Windows 10 built-in drivers worked just fine and recognizes it as "USB2.0 High-Speed True HD Audio". Its hardware ID is "USB\VID_008C&PID_0004&REV_0208&MI_00". I soldered a SPDIF header to it and have it connected to an optical/coax SPDIF board. It works, but sounds terrible at all sampling rates and bit depths - it makes bad crackling and popping sounds, and overall sounds kind of like if an amp is clipping badly.
It's plugged into the same SPDIF board as was the SPDIF output header from the Realtek ALC887 from my motherboard, and that worked just fine. I tried connecting an RCA cable to the SPDIF output on the CM6631A board and sent the TTL SPDIF directly to my AV receiver's coax input. My thinking being that TTL directly from my motherboard to receiver's coax worked, so maybe it should on the CM6631 too, but it was actually much worse.
The only thing I can think of is maybe my optical/coax board expects 5V SPDIF logic while the CM6631A outputs 3.3V, but if that's the case, why didn't it work connecting the 3.3V TTL output directly to coax input on my receiver when the receiver has no trouble with the motherboard's TTL SPDIF?
CM6631A DAC Board Digital interface card USB To IIS SPDIF Output 24Bit 192K New | eBay
Windows 10 built-in drivers worked just fine and recognizes it as "USB2.0 High-Speed True HD Audio". Its hardware ID is "USB\VID_008C&PID_0004&REV_0208&MI_00". I soldered a SPDIF header to it and have it connected to an optical/coax SPDIF board. It works, but sounds terrible at all sampling rates and bit depths - it makes bad crackling and popping sounds, and overall sounds kind of like if an amp is clipping badly.
It's plugged into the same SPDIF board as was the SPDIF output header from the Realtek ALC887 from my motherboard, and that worked just fine. I tried connecting an RCA cable to the SPDIF output on the CM6631A board and sent the TTL SPDIF directly to my AV receiver's coax input. My thinking being that TTL directly from my motherboard to receiver's coax worked, so maybe it should on the CM6631 too, but it was actually much worse.
The only thing I can think of is maybe my optical/coax board expects 5V SPDIF logic while the CM6631A outputs 3.3V, but if that's the case, why didn't it work connecting the 3.3V TTL output directly to coax input on my receiver when the receiver has no trouble with the motherboard's TTL SPDIF?
Figured it out
Nevermind, got my Ciry Audio CM6631A card working properly, turned out to be the USB cable. I switched to a fatter USB cable and now it sounds perfect. I'm guessing it wasn't getting enough power through the thinner USB cable, but not really sure.
I flashed to firmware 101 in order to get AC3/DTS compatibility, but now there are a bunch of non-existent analog audio inputs/outputs showing up. Any way to customize the firmware not to have those?
I tried that firmware updater, it's version 2,0,1,3 and didn't work in Windows 10. Newer version 2,0,1,9 that does work in Windows 10 was posted earlier in the thread:
https://www.diyaudio.com/forums/dig...m6631-usb-audio-interface-48.html#post3781527
I'd recommend that one instead because you don't need an XP machine.
Nevermind, got my Ciry Audio CM6631A card working properly, turned out to be the USB cable. I switched to a fatter USB cable and now it sounds perfect. I'm guessing it wasn't getting enough power through the thinner USB cable, but not really sure.
I flashed to firmware 101 in order to get AC3/DTS compatibility, but now there are a bunch of non-existent analog audio inputs/outputs showing up. Any way to customize the firmware not to have those?
I tried that firmware updater, it's version 2,0,1,3 and didn't work in Windows 10. Newer version 2,0,1,9 that does work in Windows 10 was posted earlier in the thread:
https://www.diyaudio.com/forums/dig...m6631-usb-audio-interface-48.html#post3781527
I'd recommend that one instead because you don't need an XP machine.
Google reports that the file is infected with a virus and does not allow download.
AC3 passthrough doesn't work well on my CM6631A. My receiver detects it as AC3/5.1CH, but it plays choppy. It plays fine through Realtek audio and Intel Display Audio. Anyone have any ideas if there's a solution for this?
Hmm it might be because it's got hex files and stuff. Bitdefender, windows defender, and norton don't report any viruses
I've been looking at the cm6631 datasheet and the dev kit posted a long time ago in the thread and was wondering if it was possible to mix inputs to a single output in the cm6631 it self, without connecting to a computer
The datasheet mentions digital mixing/routing engine to mix input to output streams but it's a very generic phrase and there's not much indication on how to achieve this.
The datasheet mentions digital mixing/routing engine to mix input to output streams but it's a very generic phrase and there's not much indication on how to achieve this.
Playback issue
I'm using the same CM6631A USB interface showed in post #809
CM6631 usb audio interface .... any good?
I have developed a simple dotnet application using NAudio library to play DC samples at different amplitudes.
When I play the samples the I2S signals are totally different than what I expected according to the data I have generated.
Amplitude and sample rate are not what I have generated.
I have just connected the oscilloscope at the output of the USB to I2S interface.
I have generated a 24 bit/192kHz DC sample at half the max amplitude (4194304), so only the MSB should be switched on (binary data attached).
When I play the sample by the Windows app the sample rate is 48kHz and several bits are on.
I've tried direct sound and WASAPI with no success.
It looks like Windows resamples arbitrarily the data I have generated.
Any idea?
I'm using the same CM6631A USB interface showed in post #809
CM6631 usb audio interface .... any good?
I have developed a simple dotnet application using NAudio library to play DC samples at different amplitudes.
When I play the samples the I2S signals are totally different than what I expected according to the data I have generated.
Amplitude and sample rate are not what I have generated.
I have just connected the oscilloscope at the output of the USB to I2S interface.
I have generated a 24 bit/192kHz DC sample at half the max amplitude (4194304), so only the MSB should be switched on (binary data attached).
When I play the sample by the Windows app the sample rate is 48kHz and several bits are on.
I've tried direct sound and WASAPI with no success.
It looks like Windows resamples arbitrarily the data I have generated.
Any idea?
Attachments
I cannot use external player unless I can manage it by my application.
I have to generate and play the sample by the Windows dotnet application.
I don't know if foobar provides the suitable library to be used in a dotnet project, I'll do a search.
BTW, I could use ASIO driver since NAudio library supports ASIO.
The pain is that I don't know if the issue comes from Windows or form the USB interface.
I have to generate and play the sample by the Windows dotnet application.
I don't know if foobar provides the suitable library to be used in a dotnet project, I'll do a search.
BTW, I could use ASIO driver since NAudio library supports ASIO.
The pain is that I don't know if the issue comes from Windows or form the USB interface.
I use this and it works well, very efficient power wise compared to xmos. I contacted the manufacturer about using it in a design and they said it's old and no longer supported.
Maybe my issue is related to the installed firmware.
It looks like the sample rate is fixed to 48kHz regardless of the original sample rate.
It looks like the sample rate is fixed to 48kHz regardless of the original sample rate.
The easiest way to use board Amanero (aliexpress). Most likely better WaveIO and I2SoverUSB v.II, but it is necessary to make a external powered.
As far I can google it, Naudio support both WASAPI Exclusive Mode and ASIO. It is a way to bypass system mixer. You need to use wrappers for these interfaces:
NAudio Output Devices
WASAPI Shared mode is not enough, as the first application that opens a pipe has a decision on the sampling rate, it is usually system sounds, still goes through mixer. To use exclusive mode, it has to be enabled in Windows Sound Control Panel.
NAudio Output Devices
WASAPI Shared mode is not enough, as the first application that opens a pipe has a decision on the sampling rate, it is usually system sounds, still goes through mixer. To use exclusive mode, it has to be enabled in Windows Sound Control Panel.
Attachments
Last edited: