CM6631 usb audio interface .... any good?

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.
 
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).

An update for my project :)

Base PCB:

An externally hosted image should be here but it was not working when we last tested it.


It can run in both USB Audio Class 1.0 or 2.0 (selectable by a jumper).

Dimensions and pinout are pretty much the same as Amanero.

Addon with an FPGA:

An externally hosted image should be here but it was not working when we last tested it.


An externally hosted image should be here but it was not working when we last tested it.


An externally hosted image should be here but it was not working when we last tested it.


It extends the base PCB with following features:

- Actual playback of 768 kHz and 705,6 kHz.
- DSD64, DSD128 and DSD256 support via DoP with seperate outputs and DSD clock (DSDL + DSDR + DSDCK).
- Serial DATA output. It does allow to connect directly any PCM DAC, e.g. in NOS mode.
- I2S output.
- Left-justified output.
- BCLK rate can be chosen between 64x and 32x Fs. Rate of 32x Fs allows to play 768 kHz files via PCM56 or 384 kHz via TDA1541(A) using serial DATA outputs.
- SPDIF output (generated on the fly directly from the incoming stream). It can generate the stream up to 384 kHz.
- Every format has an inverted output as well (connecting bunch of DAC's to create XLR output is not an issue).
- MCLK rate of 128x Fs for every sampling rate except for 705.6 kHz and 768 kHz (which is 64x Fs).
 
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.



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
 
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?
 
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 :rolleyes: btw, i have never updated the firmware or anything on the current cm6631 chip.
 
here's the image of the board i said i attached my previous post, oops. missed the edit deadline :blush:
 

Attachments

  • breeze_audio_cm6631_usb_spdif.jpg
    breeze_audio_cm6631_usb_spdif.jpg
    1,006.7 KB · Views: 552
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.
 
Last edited:
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.

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.
 
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.