2020 choice of USB/audio bridge

For anyone considering the STM32F730 or any of the other STM32 line, I would highly recommend looking up the issues encountered with the even/odd frame filter on USB Isochronous transfers. It appears to be an STM-specific "feature" and should be a huge red flag. I should mention that I actually love the STM32 line for so many other things, but I tried bringing up a UAC2 stack on the STM32F4Discovery board (as a proof-of-concept before migrating to an F7) very recently and it was an annoying roadblock to hit late. I had it fully enumerating as UAC2 and hooking into the audio subsystems of OSX. However, when receiving data, I started receiving a lot of Isochronous Incomplete interrupts/callbacks, which led me to discover this issue. The recommended fixes were patches to the USB core libraries which have since changed a decent amount. I don't have all the proper debugging tools with me (USB analyzer, JTrace, etc) to be confident in these modifications, but it's enough to make me want to try moving to an NXP chip.
 
And finally, I found the register(which marked as reserved i.e. not documented) of CT7601 with the chip ID. According to the reading of that register, the source code sets max PCM/DSD data rate limit and $2.5 version of CT7601CR doesn't play anything higher than 32/192. After I forced the code to set chip ID the same as $4.5 CT7601SR, the same cheap CT7601CR starts to play 32/384 no problem. However, DSD256 plays with noise, DSD64-128 are clear.
 
Member
Joined 2015
Paid Member
For anyone considering the STM32F730 or any of the other STM32 line, I would highly recommend looking up the issues encountered with the even/odd frame filter on USB Isochronous transfers. It appears to be an STM-specific "feature" and should be a huge red flag. I should mention that I actually love the STM32 line for so many other things, but I tried bringing up a UAC2 stack on the STM32F4Discovery board (as a proof-of-concept before migrating to an F7) very recently and it was an annoying roadblock to hit late. I had it fully enumerating as UAC2 and hooking into the audio subsystems of OSX. However, when receiving data, I started receiving a lot of Isochronous Incomplete interrupts/callbacks, which led me to discover this issue. The recommended fixes were patches to the USB core libraries which have since changed a decent amount. I don't have all the proper debugging tools with me (USB analyzer, JTrace, etc) to be confident in these modifications, but it's enough to make me want to try moving to an NXP chip.




FYI: Thesycon will soon release an UAC2 STM32 software, they certainly have solved the problem you mentioned :
Thesycon U-HEAR USB High-end Audio Receiver Firmware Solution - U-HEAR is a microcontroller-based audio streaming and processing solution for HiFi DAC and amplifier applications. - STMicroelectronics
 

I've play with this chip and also the SRC chip too long time ago.
Agree that there is no need extra MCU since for configuring DAC and also another control can be done inside the chip.

A long time ago I directly buy a couple of sample to Taiwan, but now I see there is a China agent that maybe can help:
ComTrue Inc. - Contact

Regards,
TJ.
 
Windows need the driver to play 384 and DSD, Android, iOS, Mac don't need.

I think if you use ASIO, this also won't be a big issue anymore.

Interesting thread.
I have been looking around for a similar solution for ages.
but basically it all comes done to certain license fees.
I used to work for a known company for professional radio mixers.

Today there is a high demand to be able to directly connect audio via USB.
Very quickly we discovered that you basically have to pay quite some fees to get even a driver + firmware working.
That's probably also the reason why those people weren't so keen on fixing one.

Also getting audio out, is the easy part.
Making also one with an input is another story again.

Anyway, just to share a bit of my experience;

- Technically the CP2615 (and other devices from Silabs) can do 24 bits, they don't specify the dynamic range/SNR with it.
I have been e-mailing with them back-and-forth, but they can't give any results. From the results they do show, I get a very strong feeling that it can't do much better than around 100-105dB tops.

- CMEDIA and such.
These companies basically are only interested in OEM buyers.
And even for the company I worked for the customer service wasn't so well.
My impression is that they really are only interested in big companies and/or you just really need to speak the language and understand their culture (for some Asian companies that's just really important)

- XMOS, just very expensive, and getting a license to make it work was also very expensive, unless you go up in number (> 2000 pcs or so)

So yeah, that's basically also were I stalled.
The best option I am thinking about now, is using a Raspberry Pi in "Gadget mode". Or streaming audio directly over 1Gb network to the Pi.
In theory this would work very well, with very small latency numbers
Easy implementation is a bit of thing, especially across multiple different OS's

I don't know how serious you are about getting this done, but feel free to pop me a message, so I can explain a few more details.
 
miro1360, I think it is a useless product today, the same as Ti USB audio bridges from 90th. 24/192 is minimal what could be considered as ok, better 32/384.

I think this shows a lack of understanding of DSP. Nyquist says 48kHz is fine for audio and 16 bits is plenty if you use linear volume control. You try and find a DAC that can doing anything better than 18 bits of real performance. 32 bits is the biggest waste of everyone's time, 24 is only justifiable for the 17th and 18th bits.
 
  • Like
Reactions: 1 user
I think this shows a lack of understanding of DSP. Nyquist says 48kHz is fine for audio and 16 bits is plenty if you use linear volume control. You try and find a DAC that can doing anything better than 18 bits of real performance. 32 bits is the biggest waste of everyone's time, 24 is only justifiable for the 17th and 18th bits.

funny, let me re-quote myself from another topic;

"That really depends what kind of system you're using it for from a SNR/dynamic range point of view.
16 bits is only 98dB tops. In practice it's worst.

I can tell from professional experience that this will result in audible noise in some line arrays, or compressions drivers with a very high sensitivity.
Not to mention just the extra bit of "reserves" you have with a high bit-rate.

From a samplerate point of view, that's a different story because of the lowpass effect of the human hearing.
Basically everything above 7-10kHz is pure sine-wave because of this effect."

32 bits would be nice, pure from a lab point of view, but they even can't get the full potential out of 24 bits yet (which is around 146dB)
Also, you just simply CAN'T always use linear volume control after your DSP/DAC in some cases.
 
A many Thanks for the Literature

I was interested in a compact low power bridge for a portable DAC, I start to google it and found pretty much nothing. Ok, next I googled for "USB-C 3.5mm jack teardown" and noticed bridges from Cirrus Logic, Conexant and Realtek. All these companies had no such parts officially i.e. they hide all info about USB bridges..


OMG, so glad, I found your entry. I try to figure out what's going on on the dongle market, in order to prepare for public consultancy, aiming at libraries and schools. I came across the REALTEK ALC4050, which I could grip from an American seller, but most products are obscure. The market is "hermetic" in the E.U.

What is your opinion about the USB-C chip-on-point solution, regarding the 4050 and the 9118. As far as I can tell they cover the same functions and have similar faculty. Which one would you prefer as your headphone dongle?!
I always liked the SABRÈ very much.

This is Michael from Germany,
Best regards!