USB audio class 2.0 on a microcontroller?

[SiliconWizard]

I'm looking for a working example of source code implementing USB audio class 2.0 on a microcontroller supporting USB 2.0 HS. Preferrably STM32, but doesn't really matter. I've found quite a few examples for USB audio class 1.0, but pretty much nothing for USB audio class 2.0.

An alternative would be using an XMOS-based solution, but cost would be significantly higher and then there would be the time investment with the tools/language... and possibly additional cost (I'm not sure whether XMOS USB audio library is free or not...)

So if anyone has already implemented that on an MCU or knows of such projects... Thanks!

[Doctorandus_P]

I've never done much with Audio on USB, but did a little search:

https://duckduckgo.com/html?q=USB+audio+class+2.0+
And among the first that popped up was Cmedia, and I had a peek at the 16page "datasheet" of th CM6610A.

They seem to think that high quality audio is just pushing more bits, and (as almost everybody seems to do nowadays) derive everything with a PLL from a cheap 12MHz crystal.

If you take audio seriously, then extremely stable and low jitter clocks are mandatory.
This seems to be a very often overlooked, or completely ignored fact.

If you want true 24 bit audio with a 192kHz klock, then you need to keep long term jitter in the DAC and ADC to within
>> 1/2^24/192000
ans =    3.1044e-13

Yep, that's 310 femto seconds.

Edit:
Oops, error. The sample rate should probably not be part of this equation, but the maximum signal frequency is, so it probably should be:
>> 1/2^24/20000
ans =    2.9802e-12
Which is 3ps instead of femto seconds. It does not matter much though, as accurate calculations need actual signals instead of a simple sine, but the general idea still stands. For good audio you need very accurate clocks.
(Accuracy is not the main goal, but stability is, But I'm afraid I'm getting a bit too anal here).

It's very easy to deduce that you need this accuracy.
For a simple sine(), the derivative is a cosine(), which has the same maximum value of 1.
Which means that the time resoultion for the samples is roughly equivalent to the time resolution.
Without the all invading trend of hyper compression which demolishes most audio nowaday's, audio regularly used to have a crest factor of 5 (or more) which makes it even worse.

Without acknowledging this, you will just design a 100 in a dozen mediocre audio gadged instead of a gread sounding device.

[Buriedcode]

Well, you don't need to derive the DACs clock from USB, as you're implementing it yourself, both USB Audio 1.0 and 2.0 support asynchronous mode, allowing the device to send feedback (I believe its how full its buffer is) to the host, effectively making the device the main clock that determines how many samples to send per transfer.

Also, "high quality" is a relative and somewhat vague term.  One could argue that, with 20ppm oscillators, 20-bit @ 48kHz is "high quality".  But if you're after 192kHz (for some reason) and 24-bit, then I guess it makes sense to go equally overkill on the clocks.

[SiliconWizard]

I'm going to use asynchronous mode indeed.

[NiHaoMike]

Have you considered the FX2? It handles lots of bandwidth with ease and breakout boards for it are dirt cheap thanks to its popularity as a budget logic analyzer.

[1audio]

Look up "audio widget". It's an open source implementation of UAC2 on a more general purpose platform.

Sent from my LG-H830 using Tapatalk

[SiliconWizard]

Look up "audio widget". It's an open source implementation of UAC2 on a more general purpose platform.

Apparently it would be part of this: https://github.com/borgestrand/sdr-widget ?

I'm going to take a look, thanks!

[SiliconWizard]

Have you considered the FX2? It handles lots of bandwidth with ease and breakout boards for it are dirt cheap thanks to its popularity as a budget logic analyzer.

Actually yes I have (and have already worked with FX2's in the past so that would be familiar). That's the firmware part (properly implementing UAC2) that I'm really interested in. I guess I could figure it out from the USB spec, but doing that from scratch would probably take a fair amount of time...

[DEV001]

If you want something somewhat turnkey you could use an XMOS xCORE 200 solution. They offer a USB 2.0 Audio Class dev kit which has most  of the specs you could ever want. I will admit using xTIMEcomposer and understanding their architecture takes some time but it is perfect for this type of application.

https://www.xmos.com/products/audio/kits

xCORE-200 multichannel audio platform

USB Audio Class 2.0 device
Optional Audio Class 1.0 fall-back
Low loopback latency: 3 ms
Self-powered (with Apple charging) or bus-powered
Bit perfect USB audio transfer

Info on developing audio devices: https://www.xmos.com/file/usb-audio-software-design-guide?version=latest

[ve7xen]

I'm working on a custom design around xMOS 200 series right now, actually. To just implement a basic DAC seems pretty straightforward, if you go digging around you can find several examples with code that looks modular enough to basically just reconfigure and recompile.

Unfortunately I'm having some difficulties with the JTAG interface on my boards. Not sure if I've missed something in the design (though I've carefully reviewed the requirements several times), screwed up the assembly or fried the chip somehow or what, but I can speak to the on-chip JTAG controller, but it can't enumerate the CPU. Looking for some time to continue plugging away at it. The BOM is kinda pricey so I don't just want to throw a bunch of money at building another board if it's a design issue...