Very nice. You may have raised the bar for what people want and expect from a USB audio interface card. Assuming of course, it doesn't cost so much nobody or few will want one.
It is far from being expensive, but even if it is for someone I don't mind it at all 🙂 It was fun to overclock CM6631A that much up to 768 kHz PCM and to allow it to transfer DSD256 via DoP with final decoding for separate channels and clock.
I do only play music from a computer and I do not need anything more that this interface can provide.
I do only play music from a computer and I do not need anything more that this interface can provide.
THe firmware saved my a$$et. Cannot thank those in this thread enough. Love y'all. Love this site!
...
...
Another quite interesting achievement - native DSD512 playback using CM6631A - YouTube
The project is finally done 🙂 It supports PCM playback up to 768 kHz without any decimation and DSD64, DSD128, DSD256 via DoP and DSD512 via a native method (raw data alt set descriptor).
The project is finally done 🙂 It supports PCM playback up to 768 kHz without any decimation and DSD64, DSD128, DSD256 via DoP and DSD512 via a native method (raw data alt set descriptor).
My firmware would be of no use for you without the FPGA bitstream for controlling CM6631A (it's working under slave mode).
FPGA is necessary to get every last sweat out of CM66331A. That is DSD512 and 768 kHz.
FPGA is necessary to get every last sweat out of CM66331A. That is DSD512 and 768 kHz.
Not sure about the theory of operation on this one and how makes as DoP capable running under slave mode.
For me, the USB thing has to be able to do DoP, otherwise why don't I just use I2S Dac to work with Raspberry Pi, for FLAC or DXD
DoP is nothing more than a simple two channel PCM. It works the same way except for the fact that DSD data is embedded within PCM frames and that's about it. Standard application of CM6631A will support DSD via DoP up to DSD128.
Did you actually raise the clock speed of the CM6631A, or are you able to achieve this all by using the I2S ports in slave mode?
It is a bit more complex. I did explain it all within the following post:
http://www.diyaudio.com/forums/digi...m6631-usb-audio-interface-69.html#post5453793
DSD512 is supported as well, but via a native playback and it did require even more tricks to make it work for CM6631A.
I know this is an old thread. However this CM6631A seems to be perfect for my design - a USB 2.0 Audio and MIDI interface for recording studio.
However the boards I find on eBay linked here all seem to only support DAC (output only). And the firmware tool I would like to use for the built-in 8051 CPU, however I do not know if that can support MIDI on the serial IO of the CM6631A as well.
According to the data sheet all this is possible but very little information is provided.
Please tdtsai or another user, can you help me find the correct resources?
However the boards I find on eBay linked here all seem to only support DAC (output only). And the firmware tool I would like to use for the built-in 8051 CPU, however I do not know if that can support MIDI on the serial IO of the CM6631A as well.
According to the data sheet all this is possible but very little information is provided.
Please tdtsai or another user, can you help me find the correct resources?
desolder cm6631 and replace with cm6631a
desolder cm6631 and replace with cm6631a
i've been using a cm6631 usb->spdif/toslink adapter for several years now on my x86-based server. due to some issues with skipping when the server is under heavy load, i've been working on setting up another device as a dedicated streaming device.
with the new device (an "ouya", based on nvidia tegra30 soc), i am running into an issue with the cm6631 that i never encountered when hooked up to my x86 nas. apparently randomly, the audio will become robotic sounding and distorted, as if the sample rate doesn't match the playback rate. i experienced this issue on multiple versions of the linux kernel (ancient 3.x vendor, and latest 4.18 which was released a couple days ago). it seems to be something about the tegra30 usb that triggers it.
i read that in linux, there is a workaround in the usb audio driver specifically for cm6631 and this exact issue. the problem is, the glitch that triggers it seems to happen outside of an intended sample rate change via alsa, so the workaround isn't executed. i think it is a momentary stutter or something with usb. the original fix is here: [alsa-devel] ALSA: usb: Work around CM6631 sample and another separate fix someone came up with earlier: What exactly is... : Help - Volumio
while i don't expect to fix the compatibility problem between the tegra30 usb and the cm6631, i had another idea - to desolder the cm6631 and replace it with a cm6631a, which apparently does not have that issue.
from reading this thread, it seems that i could disable the parallel flash on the board (with CE# pin) so that the cm6631a would boot from ROM. once booted from rom, i think i could re-enable the flash and use the firmware tool to flash the proper cm6631a firmare via the usb firmware tool. i got this idea from here: http://www.diyaudio.com/forums/digi...m6631-usb-audio-interface-66.html#post5376831
the board i have has an i2c or spi eeprom along with the parallel flash. maybe i should just erase it after desoldering the cm6631 chip? i have soic-8 test clips and various methods to program it (ftdi, buspirate, etc.)
attached is a picture of the board. it is the "breeze audio cm6631 usb-spdif".
thanks for any insight if this swap is possible, or if i'd just be wasting my money and ruining the board 🙄 btw, i have never updated the firmware or anything on the current cm6631 chip.
desolder cm6631 and replace with cm6631a
i've been using a cm6631 usb->spdif/toslink adapter for several years now on my x86-based server. due to some issues with skipping when the server is under heavy load, i've been working on setting up another device as a dedicated streaming device.
with the new device (an "ouya", based on nvidia tegra30 soc), i am running into an issue with the cm6631 that i never encountered when hooked up to my x86 nas. apparently randomly, the audio will become robotic sounding and distorted, as if the sample rate doesn't match the playback rate. i experienced this issue on multiple versions of the linux kernel (ancient 3.x vendor, and latest 4.18 which was released a couple days ago). it seems to be something about the tegra30 usb that triggers it.
i read that in linux, there is a workaround in the usb audio driver specifically for cm6631 and this exact issue. the problem is, the glitch that triggers it seems to happen outside of an intended sample rate change via alsa, so the workaround isn't executed. i think it is a momentary stutter or something with usb. the original fix is here: [alsa-devel] ALSA: usb: Work around CM6631 sample and another separate fix someone came up with earlier: What exactly is... : Help - Volumio
while i don't expect to fix the compatibility problem between the tegra30 usb and the cm6631, i had another idea - to desolder the cm6631 and replace it with a cm6631a, which apparently does not have that issue.
from reading this thread, it seems that i could disable the parallel flash on the board (with CE# pin) so that the cm6631a would boot from ROM. once booted from rom, i think i could re-enable the flash and use the firmware tool to flash the proper cm6631a firmare via the usb firmware tool. i got this idea from here: http://www.diyaudio.com/forums/digi...m6631-usb-audio-interface-66.html#post5376831
the board i have has an i2c or spi eeprom along with the parallel flash. maybe i should just erase it after desoldering the cm6631 chip? i have soic-8 test clips and various methods to program it (ftdi, buspirate, etc.)
attached is a picture of the board. it is the "breeze audio cm6631 usb-spdif".
thanks for any insight if this swap is possible, or if i'd just be wasting my money and ruining the board 🙄 btw, i have never updated the firmware or anything on the current cm6631 chip.
Hi,
Not sure if replacing the CM chip will solve your problem. The chip has 100 pins with 0.5mm pitch so it's not an easy job and require good tools (hot air gun, SMD microscope) But if you do go ahead with the swap:
The I2C EEPROM doesn't do anything for the 6631A, you can remove it.
If the board has a external reset delay circuit, disable it (connect XRST to gnd), otherwise the startup will be too slow resulting in the computer not recognizing the chip properly. The 6631A has an internal reset delay circuit.
The parallel flash only needs to be disabled during the fist start. As soon the chip started from ROM you can erase, restart and then program it. No need for soldering, just temporary short some pins to gnd when power up until it boots from ROM (as apposed to hanging).
Not sure if this is worth the effort as real 6631A boards are not expensive.
Not sure if replacing the CM chip will solve your problem. The chip has 100 pins with 0.5mm pitch so it's not an easy job and require good tools (hot air gun, SMD microscope) But if you do go ahead with the swap:
The I2C EEPROM doesn't do anything for the 6631A, you can remove it.
If the board has a external reset delay circuit, disable it (connect XRST to gnd), otherwise the startup will be too slow resulting in the computer not recognizing the chip properly. The 6631A has an internal reset delay circuit.
The parallel flash only needs to be disabled during the fist start. As soon the chip started from ROM you can erase, restart and then program it. No need for soldering, just temporary short some pins to gnd when power up until it boots from ROM (as apposed to hanging).
Not sure if this is worth the effort as real 6631A boards are not expensive.
Last edited:
It means phase correction for CM6631A to align BCLK towards DATA for correct output of 705.6 kHz and 768 kHz data streams.
i actually found someone local to me who has the tools/experience to do it. they said they'd done one that big before but it's been a while 🙂 personally i'd struggle to desolder an soic-8, lol.
thanks for the pointers about the i2c eeprom and reset circuit, i'll remove them. it does have the reset circuit. i saw some other posts/blogs about it, but it makes sense now thinking in terms of board vendors who used the same old CM6631 designs for the new CM6631A chip.
i'll give an update if/when this happens. i still need to source the IC.
Ok, thanks.
Is it doable to incorporate audio polarity switching, preferably by remote control ?.
Dan.
What do you mean by that? Are you referring to an inversion / negation of the audio signal? If so, that's hardly a problem. In fact, my PCB does generate both signals at the same time (normal one and an inverted version of it), so it wouldn't be a problem to switch between them via a MUX, but I don't see it being useful since both signals are only useful if you want to create a true symmetric DAC with XLR outputs.