Of course i erase the firmware. I try linux and windows 10 and work okay, only windows 7 is issue. Windows 7 sense "USB2.0 high speed HD AUDIO", but the devicemanager write "This Device Cannot Start" Code 10. I've done all the steps on the website below, but every okay. Fix: No Audio with "This Device Cannot Start. (Code 10)" Error Message - Appuals.com
What do i do to work on windows 7?
What do i do to work on windows 7?
Hey Bob_ba
I had a similar problem (code 10) in Windows 7
The problem disappeared after full Win7 update, I do not know what kind of windows patch (example: KBxxxxxx) repaired this but now my CM6631A working fine on W7. Try to update every Win7 fix patches, I think it will help.
Sorry for my english, Im too old to learn this beautiful language
Greetings
ps.: source topic of my probs with CM6631A in polish forum: CM6631A Digital Interface USB - naprawa - DIY - Audiostereo.pl
CM6632A FW tool. Any good?
Is there the usb dac confguration tool for CM6632A available?
If i understood well the tool for the 6631A is not compatible
I suppose that the USB2.0 Audio FW Update Tool 2.0.1.9 is compatible for both. Or not?
I just want to play with stereo DSD output
Mr Matt seems you have succeeded this
Have you used a prefixed hex file to update it or have you created your own?
Best Regards
Is there the usb dac confguration tool for CM6632A available?
If i understood well the tool for the 6631A is not compatible
I suppose that the USB2.0 Audio FW Update Tool 2.0.1.9 is compatible for both. Or not?
I just want to play with stereo DSD output
Mr Matt seems you have succeeded this
Have you used a prefixed hex file to update it or have you created your own?
Best Regards
Kuba, did you ever have any luck with this?
I'm trying to modify firmware for a CM6533 and don't have Keil tools.
I tried to contact "ultrabike" at superbest, but that forum is closed to new members so I couldn't message him or even post a question there
.
Ah, well, thanks. I think I have the files edited as I need (no big changes!), but need the dang Keil software suite so I can just push the button and compile it... Doing it on my own with sdcc seems to be beyond me.
I'll keep looking.
Hi everyone!
I can't understand whether it is possible for CM6632A to route audio data from the SPDIF input to the I2S output bypassing the USB input.
According to the "CM6632A Functional Block Diagram" from the Datasheet, this cannot be done because the SPDIF input via the FIFO buffer and recording DMA goes to the USB core. In the "CM66xx-A Register Spec_1.0.doc" (describing CM6632A registers definition) in the section "Digital Routing and Monitoring Control Registers" I also did not find a suitable configuration for registers to be able to route the SDIF input to the I2S output. So far, I think that this can only be done using a software mixer in the OS, which does not suit me.
Can anyone confirm or deny my assumptions?
I can't understand whether it is possible for CM6632A to route audio data from the SPDIF input to the I2S output bypassing the USB input.
According to the "CM6632A Functional Block Diagram" from the Datasheet, this cannot be done because the SPDIF input via the FIFO buffer and recording DMA goes to the USB core. In the "CM66xx-A Register Spec_1.0.doc" (describing CM6632A registers definition) in the section "Digital Routing and Monitoring Control Registers" I also did not find a suitable configuration for registers to be able to route the SDIF input to the I2S output. So far, I think that this can only be done using a software mixer in the OS, which does not suit me.
Can anyone confirm or deny my assumptions?
I've no idea if you were referring to me here!
The FW update tool will work with either the 31A or 32A but the configuration tool for the 61A will not work with the 32A.
In the SDK pack there is an example firmware
6632A-ES9018DSD-0305-ALL.hex
This works the the 6632A, enables DSD support and gives 32 bit performance at high sampling rates.
You can see the specifications for this in the DOC file that accompanies it. As far as I can see the only minor issue would be that it outputs left justified data. Most DACs can accept this if configured correctly.
So I've been working with the 6632A some more, along with the AK4499. With this combination I had been seeing a significantly elevated noise floor on the AK4499. I had assumed this was due to the implementation of the 4499 itself, but it seems like that was leading me up the garden path.
After trying a different input device it became clear that the issue was with the 6632A itself, seemingly, adding in a lot of random jitter to clocks input on XD6 and XD7. Not good. But puzzling.
As the 6632A is operating asynchronously and the data and clocks output are clocked to the oscillators it is possible to connect the oscillator outputs directly to the MCLK inputs of the DAC. This bypassas any effect the 6632A is having on the master clock jitter and with 22/24 clocks runs the DAC at 512/256/128xfs on the master clock.
Attached are pictures from ARTA of the measured results.
The first two are jitter at 44kHz. The first from the 6632, the second directly from the oscillator.
The second two are jitter at 48Khz, again the first from the 6632 and the second directly from the oscillator.
As you can see the magnitude of the spikes drops significantly as does the noise floor.
The last 4 pictures are for noise. The A weighted noise figure can be read in the bottom left. First two are 44kHz, second two are 48kHz.
Now these are the two cheapest 22/24 oscillators I could find in the SMD case style I wanted, so absolutely nothing special, yet when the DAC is directly driven by them the jitter performance is actually very good.
I also have 45/49 NZ2520SDA parts but as those operate at a much higher frequency they can't directly drive the DAC across all sample frequencies.
Directly driving the DAC from the oscillator is obviously going to give better performance, any form of buffering will degrade the overall phase noise, but this is ridiculous.
With the NDK parts going through the 6632A the noise floor characteristics remain the same as the cheap 22/24 parts going through the 6632A. So whatever is going on the 6632A is dominating things. The periodic jitter performance improves when running the NDK parts through the 6632A but the apparent random does not.
It's as if the 6632A is adding in a bunch of noise right across the board, increasing the magnitude of the noise floor and the periodic jitter spikes from the oscillator its fed. It's not adding in much by the way of it's own periodic spikes (good to see in one sense) but adding a lot of noise to everything else.
Interestingly the ADC (AK5578) doesn't seem to care about this.
The 6632A is obviously capable of more as measurements of ASUS devices will attest to.
Measurement's report ASUS Essence STU test and graphs - Reference Audio Analyzer
Measurement's report ASUS Xonar U7 Front test and graphs - Reference Audio Analyzer
You can scroll for a bunch of other measurements too.
The ASUS devices aren't expensive and use very basic implementations. Mine's far more elaborate with several low noise regulators and such. I've also tried another PCB and that didn't alter a thing.
With regards to distortion that's very low and measures to the limits of the ADC. I can get ~0.00008% etc with the right combination of levels and sampling frequencies. So no problem there.
I've tried altering all sorts of settings from the SDK, enabling and disabling different PLLs. Changing the feedback settings from off, to on, to MCU controlled. Pure PLL was horrendous, the noise floor jumped up to -92dBA, which seems malfunction levels of wrong.
I've also disabled all the i2c writes/reads in the SDK as I'm not using that functionality. I figured maybe the 8051 kept retrying the i2c commands when it didn't get the response back from the chips it was trying to control and that was generating internal noise. This didn't do anything.
I've tried different USB ports. Different computers. Different USB cables too. Nothing changes.
So something is going on inside the 6632A that shouldn't be.
So we've got implementation, both software and hardware. Or the 6632A is a counterfeit/reject.
I would be surprised if the hardware implementation is what's causing the problem as I've tried a different PCB layout and it didn't do anything at all. I've also tried adding in extra bulk decoupling. As you'd expect this gives a measurable improvement across the decouplers next to the IC pins with regards to transient spikes/dips, but it doesn't change anything.
The software, and device configuration, could easily have something within it that's causing a problem although I am not sure what.
And then there's the counterfeit/reject hypothesis. I did get my 6632A from Aliexpress. I highly doubt there's a big enough market for a counterfeit operation to make financial sense but I could see someone reselling operational, but substandard, rejects.
Currently I am thinking about adding in a low jitter clock distribution device to handle the oscillators and master-clock routing/division to the various devices, using the 6632A to control it. This should solve the problem and give better jitter performance than a properly functioning 6632A anyway. I'm fine with going this route as a one off, but I want to be able to use the 6632A in other things I build without a separate clock routing device.
Anyone any ideas?
P.S. Yes I know you can buy from the authorised distributor, Symmetry, but postage was prohibitively expensive. They wanted several times the cost of the device just to ship it. TI can ship global priority for a few dollars, why can't you?
After trying a different input device it became clear that the issue was with the 6632A itself, seemingly, adding in a lot of random jitter to clocks input on XD6 and XD7. Not good. But puzzling.
As the 6632A is operating asynchronously and the data and clocks output are clocked to the oscillators it is possible to connect the oscillator outputs directly to the MCLK inputs of the DAC. This bypassas any effect the 6632A is having on the master clock jitter and with 22/24 clocks runs the DAC at 512/256/128xfs on the master clock.
Attached are pictures from ARTA of the measured results.
The first two are jitter at 44kHz. The first from the 6632, the second directly from the oscillator.
The second two are jitter at 48Khz, again the first from the 6632 and the second directly from the oscillator.
As you can see the magnitude of the spikes drops significantly as does the noise floor.
The last 4 pictures are for noise. The A weighted noise figure can be read in the bottom left. First two are 44kHz, second two are 48kHz.
Now these are the two cheapest 22/24 oscillators I could find in the SMD case style I wanted, so absolutely nothing special, yet when the DAC is directly driven by them the jitter performance is actually very good.
I also have 45/49 NZ2520SDA parts but as those operate at a much higher frequency they can't directly drive the DAC across all sample frequencies.
Directly driving the DAC from the oscillator is obviously going to give better performance, any form of buffering will degrade the overall phase noise, but this is ridiculous.
With the NDK parts going through the 6632A the noise floor characteristics remain the same as the cheap 22/24 parts going through the 6632A. So whatever is going on the 6632A is dominating things. The periodic jitter performance improves when running the NDK parts through the 6632A but the apparent random does not.
It's as if the 6632A is adding in a bunch of noise right across the board, increasing the magnitude of the noise floor and the periodic jitter spikes from the oscillator its fed. It's not adding in much by the way of it's own periodic spikes (good to see in one sense) but adding a lot of noise to everything else.
Interestingly the ADC (AK5578) doesn't seem to care about this.
The 6632A is obviously capable of more as measurements of ASUS devices will attest to.
Measurement's report ASUS Essence STU test and graphs - Reference Audio Analyzer
Measurement's report ASUS Xonar U7 Front test and graphs - Reference Audio Analyzer
You can scroll for a bunch of other measurements too.
The ASUS devices aren't expensive and use very basic implementations. Mine's far more elaborate with several low noise regulators and such. I've also tried another PCB and that didn't alter a thing.
With regards to distortion that's very low and measures to the limits of the ADC. I can get ~0.00008% etc with the right combination of levels and sampling frequencies. So no problem there.
I've tried altering all sorts of settings from the SDK, enabling and disabling different PLLs. Changing the feedback settings from off, to on, to MCU controlled. Pure PLL was horrendous, the noise floor jumped up to -92dBA, which seems malfunction levels of wrong.
I've also disabled all the i2c writes/reads in the SDK as I'm not using that functionality. I figured maybe the 8051 kept retrying the i2c commands when it didn't get the response back from the chips it was trying to control and that was generating internal noise. This didn't do anything.
I've tried different USB ports. Different computers. Different USB cables too. Nothing changes.
So something is going on inside the 6632A that shouldn't be.
So we've got implementation, both software and hardware. Or the 6632A is a counterfeit/reject.
I would be surprised if the hardware implementation is what's causing the problem as I've tried a different PCB layout and it didn't do anything at all. I've also tried adding in extra bulk decoupling. As you'd expect this gives a measurable improvement across the decouplers next to the IC pins with regards to transient spikes/dips, but it doesn't change anything.
The software, and device configuration, could easily have something within it that's causing a problem although I am not sure what.
And then there's the counterfeit/reject hypothesis. I did get my 6632A from Aliexpress. I highly doubt there's a big enough market for a counterfeit operation to make financial sense but I could see someone reselling operational, but substandard, rejects.
Currently I am thinking about adding in a low jitter clock distribution device to handle the oscillators and master-clock routing/division to the various devices, using the 6632A to control it. This should solve the problem and give better jitter performance than a properly functioning 6632A anyway. I'm fine with going this route as a one off, but I want to be able to use the 6632A in other things I build without a separate clock routing device.
Anyone any ideas?
P.S. Yes I know you can buy from the authorised distributor, Symmetry, but postage was prohibitively expensive. They wanted several times the cost of the device just to ship it. TI can ship global priority for a few dollars, why can't you?
Attachments
Asus Thunderbolt
Hi, every body!
I have had a problem with the cmedia 6631 chipset audio card (not 6631A) in ROG ThunderBolt LAN / Audio Combo
The sound was failing me on the ROG ThunderBolt LAN / Audio Combo and I decided to update the firmware of the thunderbolt sound card (CMedia 6631) for another that was not official of those in this thread
and obviously it didn´t work, so I didn´t do a firmware backup.
Now I want to go back to the original version and I can't because I don't have the firmware
and in the asus download center there isn´t firmware for the ROG ThunderBolt LAN / Audio Combo...
Then surfing the internet I found this web with a lot of information about cm6631, cm6631a, etc...
I was testing several firmwares, many of them load in the thunderbolt and windows recognizes the thunderbolt perfectly (True HD audio, even firmware essence one), but it isn´t heard... The update tool only has the functions of update and erase firmware, but not of making backups... is there a way to backup the cm66xx chipset? Thanks and sorry for may bad english ... Regards.
Hi, every body!
I have had a problem with the cmedia 6631 chipset audio card (not 6631A) in ROG ThunderBolt LAN / Audio Combo
The sound was failing me on the ROG ThunderBolt LAN / Audio Combo and I decided to update the firmware of the thunderbolt sound card (CMedia 6631) for another that was not official of those in this thread
and obviously it didn´t work, so I didn´t do a firmware backup.
Now I want to go back to the original version and I can't because I don't have the firmware
and in the asus download center there isn´t firmware for the ROG ThunderBolt LAN / Audio Combo...Then surfing the internet I found this web with a lot of information about cm6631, cm6631a, etc...
I was testing several firmwares, many of them load in the thunderbolt and windows recognizes the thunderbolt perfectly (True HD audio, even firmware essence one), but it isn´t heard... The update tool only has the functions of update and erase firmware, but not of making backups... is there a way to backup the cm66xx chipset? Thanks and sorry for may bad english ... Regards.
Posting an update to this.
I've built up another device around the CM6632A using the PCM1792A.
My previous issue with the CM6632A adding in a bunch of random jitter to the signal is also present with the PCM1792A as it was with the AKM4499. This reduces the dynamic range of the 1792A by raising the noise floor by a few dB.
This thread probably receives a very minimal amount of traffic but does anyone know an easy way to remove unwanted audio endpoints from the SDK?
For example the basic configuration (6631A_6632A design example) is a complete interface utilising every endpoint possible for the device. If, for example, I wanted to remove the speakers output, one of the ADC inputs and both SPDIF endpoints from the design how would I do it?
To anyone who has done it is there an easy way to do this? I've tried commenting out the various endpoints...
"&g_Audio20InterfaceSpeaker,"
in the device.c file, for example, figuring it might do the job, it did not. Trouble here is that it still compiled, but when used it bricked the CM6632A requiring the flash memory to be wiped before it would work again. This was unexpected and not at all welcome. I don't mind messing about with the code if the compiler will throw me errors but no errors and bricks are not wanted.
Obviously this isn't critical it's more just a ease of life thing.
I've built up another device around the CM6632A using the PCM1792A.
My previous issue with the CM6632A adding in a bunch of random jitter to the signal is also present with the PCM1792A as it was with the AKM4499. This reduces the dynamic range of the 1792A by raising the noise floor by a few dB.
This thread probably receives a very minimal amount of traffic but does anyone know an easy way to remove unwanted audio endpoints from the SDK?
For example the basic configuration (6631A_6632A design example) is a complete interface utilising every endpoint possible for the device. If, for example, I wanted to remove the speakers output, one of the ADC inputs and both SPDIF endpoints from the design how would I do it?
To anyone who has done it is there an easy way to do this? I've tried commenting out the various endpoints...
"&g_Audio20InterfaceSpeaker,"
in the device.c file, for example, figuring it might do the job, it did not. Trouble here is that it still compiled, but when used it bricked the CM6632A requiring the flash memory to be wiped before it would work again. This was unexpected and not at all welcome. I don't mind messing about with the code if the compiler will throw me errors but no errors and bricks are not wanted.
Obviously this isn't critical it's more just a ease of life thing.
5th, what tool are you using for the compiler/linker for the chip's object code?
I've changed some endpoints for CM6533, making it a record-only device, it wasn't too hard. One of the settings in the Ccode for the USB is how many endpoints, or the length of each, I don't remember off-hand. It helped that I have several example codes for setting up the chip for different uses.
I've changed some endpoints for CM6533, making it a record-only device, it wasn't too hard. One of the settings in the Ccode for the USB is how many endpoints, or the length of each, I don't remember off-hand. It helped that I have several example codes for setting up the chip for different uses.
It's a version of the Keil compiler. It's possible that as well as commenting out the specific endpoints themselves that I have to alter the number of end points too. There are configurable settings as such but quite a few of them throughout the device build-up. I just figured if there was one thing you could comment out to remove one end point from the who thing I would ask!