What about this one ? MCHStreamer - USB Audio Swiss-Army knife - Multichannel PCM/DSD/PDM/ADAT/TDM/SPDIF interface Minidsp is usually fairly reliable.
I see it’s based on XMOS, I wonder how they made it 8 channels bidirectional (if that’s accurate). But nevertheless, for $150 cost, shipping, taxes, I could get 5 TMSxxx DSP chips or a couple of FPGAs and do it myself - the problem is, ADC + DAC + CPLD + FPGA + USB is about 25% the promotional price of Jen’s analyzer in silicon only. Totally non economic.
Plus that I don’t like closed solutions with no access to source code.
Plus that I don’t like closed solutions with no access to source code.
Last edited:
CM6631/2A is usable I believe, there is an SDK and better datasheets available if you message user tdtsai on DiyAudio. It won't do more than 384 kHz - I believe. The XMOS is an option.
Your other option is to go the non-audio route like QuantAsylum. QA401 uses a Cypress FIFO to USB bridge. These use bulk transfers and you have to install Cypress' drivers and write an app using their API. FTDI has similar chips, I am planning to use an FT600Q at work with D3XX driver and API to transfer around 800 Mbit/s.
The problem is the amount of time it actually takes to develop a USB UAC 2.0 compliant device and test it. If you choose to implement your own protocol on top of USB now you are stuck writing Windows or Linux audio device drivers. That's why people buy the XMOS garbage.
Thesycon is licensing a solution for an STM32F7 MCU but it may have some limitations because it's using the ST Micro SAI peripherals which may not support above 192 kHz easily.
That’s exactly my position. Implementing for example SPI over an USB transport is feasible (not necessary a piece of cake, though), but then what? Writing Windows/Linux drivers to interface with ARTA, etc... is not my kind of hobby.
Thesycon drivers appear to be expensive to license and hence are definitely not DIY material. They smell, walk and quack as a mass production intended product.
Based on the (mostly marketing) materials I’ve seen about C-Media, their stuff appears to be a good solution. But then who knows what’s under the hood, and they seem to be in the same boat as ESS, total lack of documentation, demos, distribution channels, etc...
Edit: saw your other message about C-Media, I’ll try and see what I can get.
Last edited:
The CM663xA are basically 8051 MCUs with their own I2S peripherals. I haven't really used them but I planned on it at one point. You'll need a copy of the Keil C51 compiler to build their code but it seems like it should be workable overall.
Wait a second now the cmedia solution isn't as tragic as it at first seems. Along with all of the documentation that tdtsai provides are firmware examples for fully functional hardware configurations for both the 31 and 32.
Cmedia officially don't require you to sign NDAs anymore, as far as I know, and appointed tdtsai, an engineer at cmedia, to collaborate with DIYers in getting their chips to work.
The 32A is a multichannel part and with the stock firmware gives a combination of 8 linked output channels, an additional 2 channel output and 2x two channel inputs.
In other words the device could be providing 8 channels surround sound to one room, stereo to a headphone user, a stereo ADC for the headphone users microphone in their gaming headset and another ADC input for something random. All of these can be operating simultaneously and at different sample frequencies up to 24/192kHz.
The 31A does exactly the same as above except the 8 channel audio block is replaced with a 2 channel. It will, however, work all the way up to 384kHz.
There are circuit diagrams for device implementation along with tdtsai's information but basically you need to provide a serial flash memory chip to contain the firmware for the cmedia chip, a 12MHz crystal/oscillator (either will work) for device operation and two oscillators, one at 45.xxxMHz and one at 49.xxxMHz for the generation of the audio clocks.
If you read through the thread that tdtsai participates in you'll find links to all the required files to make things work.
The stock configuration isn't perfect as it uses some odd combinations of bit clock rate to sample rate at lower sampling frequencies, but if you're sending the i2s stream through an FPGA anyway this won't be a problem. The important thing is that it uses asynchronous isochronous transmission as standard and actually works straight out of the box, at least with windows 10, you don't need device drivers they are now included with windows.
If you had the Kiel stuff you could change the clocking scheme, the i2s data formats and reprogram the names of the inputs/outputs as seen by windows. But things are quite functional as standard. Why cmedia chose something as dated as the 8051 I don't know. If they'd embedded a microchip device they could have used the free to download MPLAB, it's associated compilers, and probably done away with the separate required memory chip. Who knows.
Cmedia officially don't require you to sign NDAs anymore, as far as I know, and appointed tdtsai, an engineer at cmedia, to collaborate with DIYers in getting their chips to work.
The 32A is a multichannel part and with the stock firmware gives a combination of 8 linked output channels, an additional 2 channel output and 2x two channel inputs.
In other words the device could be providing 8 channels surround sound to one room, stereo to a headphone user, a stereo ADC for the headphone users microphone in their gaming headset and another ADC input for something random. All of these can be operating simultaneously and at different sample frequencies up to 24/192kHz.
The 31A does exactly the same as above except the 8 channel audio block is replaced with a 2 channel. It will, however, work all the way up to 384kHz.
There are circuit diagrams for device implementation along with tdtsai's information but basically you need to provide a serial flash memory chip to contain the firmware for the cmedia chip, a 12MHz crystal/oscillator (either will work) for device operation and two oscillators, one at 45.xxxMHz and one at 49.xxxMHz for the generation of the audio clocks.
If you read through the thread that tdtsai participates in you'll find links to all the required files to make things work.
The stock configuration isn't perfect as it uses some odd combinations of bit clock rate to sample rate at lower sampling frequencies, but if you're sending the i2s stream through an FPGA anyway this won't be a problem. The important thing is that it uses asynchronous isochronous transmission as standard and actually works straight out of the box, at least with windows 10, you don't need device drivers they are now included with windows.
If you had the Kiel stuff you could change the clocking scheme, the i2s data formats and reprogram the names of the inputs/outputs as seen by windows. But things are quite functional as standard. Why cmedia chose something as dated as the 8051 I don't know. If they'd embedded a microchip device they could have used the free to download MPLAB, it's associated compilers, and probably done away with the separate required memory chip. Who knows.
Sorry, I'm new to this stuff, I may have missed something, can you point me to this thread and perhaps relevant tdtsai posts? You mean, this one? Doesn't seem to be much of DIY inside, but then again, I have not read the whole thread.
Thanks, got the downloads.
Anybody knows more about this CM6631A-EVAL board and a distributor? Google returns CM6631A-EVAL - USB 2.0 High-Speed True HD Audio Processor Eval Board It appears it's the only on the planet advertising this board (apparently as pre-order?), never heard before of these guys, are they an official C-Media distributor?
Anybody knows where I can buy a few CM6631A chips? The usual distributors do not seem to carry them, the same company apparently does CM6631A - USB 2.0 High-Speed True HD Audio Processor No distributors listed on the C-Media web site, very strange.
The 8051 is probably cheap to buy an IP core of. I'm not aware of Microchip selling PIC designs to anyone else to embed. It's a bit of an older product, I bet a new one would use an ARM Cortex M0+ or free RISC-V. I am sure the chip is cheaper and easier to fab without embedded flash.
Symmetry is their distributor I think. I have not ordered C-Media parts from them, but I have ordered Telit LTE radio modules from them before and had no problems.
I can tell, the 8051 is offered as a macro cell in any design kit I’ve seen from silicon foundries. The standard version runs at 12MHz, but I’ve seen some versions specified up to 40MHz, which is quite an achievement for this venerable CISC chip.
Yep, after reading more of that thread, it appears the CM6631A could be a rather quick winner... but it is still not an out of the box connectivity solution, and I would expect some quirks on the way.
However, I’m not at all excited to go back to low level 8bit code, wondering if taking the upfront path would not be actually a more compelling and fun approach. A TI OMAP-L137 DSP chip monster is $30, has all the required features and a ton extra, could do the SPI to I2S translation in software on the fly, even with brute force bit banging (so no more Altera CPLD), the CCS compiler is free for use with a demo board, comes with a RTOS, it is well supported by TI and the community, the free code base and samples is large (it may even have something very close to what’s needed here). Which pretty much makes this OMAP DSP approach a 95% software project.
I’ll give it a second thought and be back as soon as I’ll make a decision where to go...
However, I’m not at all excited to go back to low level 8bit code, wondering if taking the upfront path would not be actually a more compelling and fun approach. A TI OMAP-L137 DSP chip monster is $30, has all the required features and a ton extra, could do the SPI to I2S translation in software on the fly, even with brute force bit banging (so no more Altera CPLD), the CCS compiler is free for use with a demo board, comes with a RTOS, it is well supported by TI and the community, the free code base and samples is large (it may even have something very close to what’s needed here). Which pretty much makes this OMAP DSP approach a 95% software project.
I’ll give it a second thought and be back as soon as I’ll make a decision where to go...
Last edited:
I'd prefer an ARM Cortex M4F or M7 for this and think the tools are better, but you could do it in a C6000 I am sure. TI had a USB audio example project for the C5535 years ago, but it was fairly limited. The problem is, their example firmware was not using asynchronous endpoints. It's certainly doable but a lot of work to implement USB Audio Class 2.0.
That would be my next investigation, I would think this is something that’s already considered and somehow implemented in the user community. I’ll download the CCS and peek in the libraries, to start with.
The OMAP-L137 is a C6000 DSP + ARM9 core, BTW. One thing that kills my enthusiasm right now is that it comes as a BGA only, meaning outsourcing hardware
An expensive proposition for DIY.
My latest project based on same concept, targeting evaluation audio OPA in 20k-200k band. SAR adc ad7984
PulSAR ADC PMODs [Analog Devices Wiki]
data processing on nucleo-H743 (stm32H743). Display 320x480, fft-32k, sampling up to 1.2Msps.
I came across ads127l in my initial research, but TI doesn't have affordable eval-module so I went with analog D. Have tested also single ended ad7983, ad7988-5 ( 7984 - diffe
rential). Another suspicious nuance about ads127 is all I can see in DS specification for THD is only at 4kHz. What I observed with AD, that things is not goes well above 10kHz, THD drops and at 100k I hardly could get -90 thd-3.
How it looks:
PulSAR ADC PMODs [Analog Devices Wiki]
data processing on nucleo-H743 (stm32H743). Display 320x480, fft-32k, sampling up to 1.2Msps.
I came across ads127l in my initial research, but TI doesn't have affordable eval-module so I went with analog D. Have tested also single ended ad7983, ad7988-5 ( 7984 - diffe
rential). Another suspicious nuance about ads127 is all I can see in DS specification for THD is only at 4kHz. What I observed with AD, that things is not goes well above 10kHz, THD drops and at 100k I hardly could get -90 thd-3.
How it looks:
I have a CMedia eval board I could send you if that would help. Its loaded with different stuff (ADC, DAC's and headphone drivers). CMedia are good to deal with. The audiophile market is small for them. They sell millions of USB audio chips for cheap USB speakers etc. Still they were good to work with.
I also have that TI demo board if I can find it.
And there is the Open-source USB interface: Audio Widget and related SDR widget PCB group buy (USB 24/192 IN-OUT). I think I have an extra interface PCB for that which I can also send.
I also have that TI demo board if I can find it.
And there is the Open-source USB interface: Audio Widget and related SDR widget PCB group buy (USB 24/192 IN-OUT). I think I have an extra interface PCB for that which I can also send.