Custom Audio DSP with USB and I2S or TDM

[AaronD]

Looking at this or similar, but not married to anything in particular:
https://www.microchipdirect.com/product/ATSAM4S16CB-AN

I think my biggest problem will be to graduate up from PIC16's and ATmega's with all custom code and no libraries*, to something that can handle the throughput that something like this requires!  (I looked briefly at a PIC16F1454, but when the maximum instruction rate is the same as an external bit clock...ehh, no.)

^{(*It took some effort to convince the PIC port of SDCC to not add the C-standard init code, but go directly to my main() function instead.  Turns out you just name it something else so that there is no main(), and then map an inline assembly function at the reset vector to long-jump to wherever the linker decides to put your renamed_main().  Then YOU are responsible to initialize everything...or not as the case may be.)}

Is the above a good chip to pick?  Is there a better one?  Why for both of those questions?  What (free!) toolchain and possible libraries do I need, considering the possibility of some commercial projects later on?  (GCC and Code::Blocks would be nice, as I already know them from some AVR projects, but others would be okay too)  How to manage a DMA?  Etc.


I want to start with this block diagram, just to get my feet wet, and I have a project that can use it anyway:

+------------------------------+                                               
| USB Composite Device         |        +----------+        +------------------+
| - 2-ch Audio                 |------->|    DSP   |------->| 2.1 Speaker Out  |
| - HID for custom control app |        +----------+        +------------------+
+------------------------------+              |                                 
                                              |                                 
                                    +-------------------+                       
                                    | Physical Controls |                       
                                    | - Potentiometers  |                       
                                    | - Encoders        |                       
                                    | - Buttons         |                       
                                    | - LED's           |                       
                                    +-------------------+                       

It's pretty much what you'd think: a stereo-input USB sound card with EQ and crossover to stereo tops and a mono sub, plus some direct physical controls.  If it weren't for the physical controls, I could just buy that instead of making one, but the bigger purpose is to learn the building blocks to then do this:

            +------------------+        +----------+        +----------------------+
            | Stereo Mic In    |------->|          |------->| Stereo Line Out      |
            +------------------+        |          |        +----------------------+
                                        |          |                               
            +------------------+        |          |        +----------------------+
            | Stereo Mic In    |------->|          |------->| Stereo Speaker Out   |
            +------------------+        |          |        +----------------------+
                                        |    DSP   |                               
            +------------------+        |          |        +----------------------+
            | Stereo Line In   |------->|          |------->| Mono Line Out        |
            +------------------+        |          |        +----------------------+
                                        |          |                               
+------------------------------+        |          |        +----------------------+
| USB Composite Device         |<------>|          |------->| Mono Speaker Out     |
| - 8-ch in / 8-ch out Audio   |        +----------+        +----------------------+
| - HID for custom control app |                                                   
+------------------------------+                                                   

That's a total of 6 channels in and 6 channels out of analog audio (counting amplified speakers as analog to allow for digital-input class-D amp chips), for either 3x I2S streams between the ADC's and DAC's/amps, or 1x TDM-8 for all of it.

I2S looks similar enough to SPI that I might be able to use a SPI peripheral to fake it?  And TDM is based on I2S with the same similarities, so maybe I can still use a SPI peripheral for that?  The bit clock of TDM-8, 32-bit, 48kHz, is just a hair above 12MHz, so it'd have to be a pretty fast chip compared to what I'm used to, just for that.

The analog-to-analog signal path of this one has a very tight constraint on the overall latency - there are two mic-to-speaker paths in there, with just a handful of samples' worth of distance at 48kHz through some foam, and the DSP's purpose is mostly to undo the foam's acoustic lowpass (plus some transducer correction and limiting) - so I think I need to write my own transport and DSP code to operate on single samples instead of a block of 64 or so like I see being common, just to have the acoustic and electronic wavefronts line up.  I think I'm okay with writing the DSP code; from what I've seen on Wikipedia and some dedicated DSP coding sites, that part should be easy once I get a new chip up and running in the first place.

USB has so such requirement: it's pretty much a monitor for recording/debugging at several different points simultaneously along the processing chain, so it can fill up a buffer and send it off whenever it gets around to it.  Likewise in the other direction, it can get a buffer from USB and then play it out.  That's fine; the critical latency doesn't apply to this connection.

And like the diagram says, drop the physical controls for this one.  But I might add some other functionality, unrelated to audio, depending on the amount of CPU time and other resources that I have left over.


For both projects, I think I want the DSP chip to have the master clock (and give it a good one!), and everything else slaves to that, including USB, which would then need to run its audio interface in "asynchronous" mode.  Don't need any options for USB Audio: just 2 or 8 channels (depending on the project) of 32-bit integer at 48kHz, and that's it.  Not even any controls, as the DSP code (with its custom HID connection and corresponding app) covers that and more.

[moffy]

The NXP iMXRT1010, iMXRT1020 ... all the way up to the iMXRT1060(there are last digit variations within each group) have a 500/600MHz ARM M7 core with lots of peripherals. The 1010 and 1020 are LQFP the rest are BGA. Value for the range is exceptional and the 1020 EVK board comes with an on board audio CODEC with audio software examples via USB. The grandest chip is the iMXRT1172 which is dual core, one at 1000MHz and the other at 400Mhz and heaps of audio interfaces. You could use the 400MHz core to control the peripherals and the 1000MHz core as your DSP. Hope that helps.

[ataradov]

If you a just starting and planning on using vendor libraries, I would not use SAM4S. It is an older device, which is not supported by modern libraries. You would have to deal with old libraries that are mostly out of support now. They are still functional, of course, but may not be the best starting point.

I would also try to avoid using SPI for I2S emulation. It would be hard to get the timings consistent.

Start with more recent devices.

[Marco]

Does it have to work with windows <10?

[tszaboo]

SPI as I2s: Nope, you have more signals, so DMA wouldn't work, and your micro would spend most of it's time in interrupt for that many channels. And I2S carries playback speed, so you need precise control over it's speed, so extra hardware in the micro.
USB: Just note that most microcontroller have USB 1.1 speed, 12MBPS. If you playback 16x channel at 16 bits @ 48 KHz, you are above that, AFAIK you can fit maybe 6 channel on a Audio class 1 device. Going to Audio class 2 limits the available micros a lot, simply because they just don't have example firmware.

[AaronD]

The NXP iMXRT1010, iMXRT1020 ... all the way up to the iMXRT1060(there are last digit variations within each group) have a 500/600MHz ARM M7 core with lots of peripherals. The 1010 and 1020 are LQFP the rest are BGA. Value for the range is exceptional and the 1020 EVK board comes with an on board audio CODEC with audio software examples via USB. The grandest chip is the iMXRT1172 which is dual core, one at 1000MHz and the other at 400Mhz and heaps of audio interfaces. You could use the 400MHz core to control the peripherals and the 1000MHz core as your DSP. Hope that helps.

I'll have to poke around that family for a while and see what's there.  Thanks!  That last one looks especially interesting, but probably overkill too.  Not necessarily bad though.

What does that ecosystem look like?  Supported IDE's, compilers, debuggers, etc.  Preferably all free except for the hardware, and even that's fairly cheap to buy or easy to make (or universally compatible with everyone to justify a higher cost), and take advantage of any "special instructions" that a chip may have, instead of taking 10 or so to beat around the bush "the old fashioned way" that the special instructions are specifically meant to avoid.

I'm not so sure about BGA packages, but that could just be a residual phobia from when I only did through-hole because that's all I could solder by hand with one iron.  Now that I've made a toaster reflow oven (and made a custom surface-mount control board for it by hand with hot air) and done a few boards in there, and hot-air-reflowed a QFN, maybe BGA isn't off-limits anymore either.  Just never tried it yet.

If you a just starting and planning on using vendor libraries, I would not use SAM4S. It is an older device, which is not supported by modern libraries. You would have to deal with old libraries that are mostly out of support now. They are still functional, of course, but may not be the best starting point.

Start with more recent devices.

Ah!  Okay, that makes sense.  That was just what came to the top in a preliminary search for what I thought might be a decent guess at specs, then sorted by price.  Like I said, I'm not married to it at all.

I would also try to avoid using SPI for I2S emulation. It would be hard to get the timings consistent.

I'm not entirely sure what you mean there.  The only thing I can think of might be the left/right clock for I2S or the sample clock for TDM, which would probably have to be bit-banged or generated by a different peripheral if I used SPI to emulate the data.  I can see that being tricky, but the bit-clock should be fine as that's still part of SPI.  It's also a slight difference that SPI is byte-oriented and I2S/TDM are word-oriented, but a DMA to my understanding (and maybe a union in C, between the two data structures) should sort that out automatically, right?

Does it have to work with windows <10?

Fully-updated Raspbian / Raspberry Pi OS for both.  (based on Debian, like some other popular Linux distros)  But if it's actually USB-standards-compliant, that shouldn't matter at all, I would think.

SPI as I2s: Nope, you have more signals, so DMA wouldn't work, and your micro would spend most of it's time in interrupt for that many channels.

Yes, there's also a level-triggered left/right clock for I2S, or an edge-triggered frame/sample clock for TDM.  (and there are far more bits per frame in TDM, all concatenated together so that a receiver has to count bits to separate the channels)  That higher-level, 48kHz clock would have to be created separately if I used SPI as I2S or TDM.  But a DMA can still reduce the number of interrupts by transferring an entire 32-bit channel or even a 256-bit TDM frame without CPU intervention, right?

And I2S carries playback speed, so you need precise control over it's speed, so extra hardware in the micro.

I2S carries playback speed?  So extra hardware?  How?  I thought it was just a synchronous serial line with two clocks: a bit clock to run the shift registers, and a frame clock to latch the SR's into their respective sample buffers.  Likewise for TDM, except that a frame is now many samples concatenated together instead of just two, and the frame clock only cares about the leading edge of the entire frame instead of denoting immediately what channel is being transferred at the moment.  So the "playback speed" is simply the sample rate, right?

Given that, the precise speed can simply be bit-banged using a top-priority interrupt if necessary.  Yes, it takes some CPU time to do that, counting interrupt latency and a handful of instructions to actually do it, but surely not excessive.
Or perhaps use a different hardware peripheral to generate a free-running 48kHz output, and then slave the DMA to that to feed the SPI peripheral?  Then the whole thing just runs on its own with no CPU intervention at all except to run the DSP code between the single-sample-for-all-channels endpoint buffers.  (in addition to triggering the DMA to transfer one entire frame and then wait for the next trigger, that free-running output also triggers a high-priority interrupt that has all of the DSP code in it)

Of course, if there IS a complete TDM peripheral, or multiple I2S's, THEN USE THAT!!  I just haven't seen one yet, except in a purpose-designed DSP chip that is effectively locked to its vendor IDE* and doesn't have USB**.

<sup>(*Analog Devices has a good one, if it weren't for the block-size that equates to that many samples of latency.  Most applications won't notice that, but I think that my second one will, as phasing issues.)

(**That's almost a deal-breaker because of the ridiculous overkill that it seems to take just to convert a bidirectional TDM-8 stream into a bidirectional 8-ch USB Audio stream.  There seem to be no drop-in chip that "just does that", so it needs a microcontroller and firmware for just that one job...or as the entire DSP itself, which is what I'm looking at here.)</sup>

USB: Just note that most microcontroller have USB 1.1 speed, 12MBPS. If you playback 16x channel at 16 bits @ 48 KHz, you are above that, AFAIK you can fit maybe 6 channel on a Audio class 1 device. Going to Audio class 2 limits the available micros a lot, simply because they just don't have example firmware.

Hmm...okay.  I hadn't run into that yet, but it makes sense.  And I probably *will* run into it during the second, more ambitious part.  Thanks for the warning!

[ve7xen]

I'm not entirely sure what you mean there.  The only thing I can think of might be the left/right clock for I2S or the sample clock for TDM, which would probably have to be bit-banged or generated by a different peripheral if I used SPI to emulate the data.  I can see that being tricky, but the bit-clock should be fine as that's still part of SPI.  It's also a slight difference that SPI is byte-oriented and I2S/TDM are word-oriented, but a DMA to my understanding (and maybe a union in C, between the two data structures) should sort that out automatically, right?

I would also avoid this. Generating the LRCLK with one channel of a multi-channel SPI peripheral (or divided down from your bit clock) is probably possible, and maybe you can use a PLL to generate the correct bit clock to avoid external clock generation. If using 32bit I2S it's probably not that bad, but also sounds like there's a lot of potential for gotchas and it's just another thing to waste time on niggly details. Lots of micros have I2S peripherals, or an I2S mode in their SPI peripherals. It shouldn't be hard to find something suitable, so I wouldn't consider this.

USB: Just note that most microcontroller have USB 1.1 speed, 12MBPS. If you playback 16x channel at 16 bits @ 48 KHz, you are above that, AFAIK you can fit maybe 6 channel on a Audio class 1 device. Going to Audio class 2 limits the available micros a lot, simply because they just don't have example firmware.

Hmm...okay.  I hadn't run into that yet, but it makes sense.  And I probably *will* run into it during the second, more ambitious part.  Thanks for the warning!

You'll definitely want Audio Class 2 to do multichannel. In theory you could implement this on any USB2.0 High Speed controller, but as pointed out, there's not great example firmware out there.

You may consider XMOS XU series devices. They are basically designed for this purpose, there is existing AC2 demo code that works well (though I wouldn't really call it 'good code'), an App Note that covers how to add basic DSP to it, and they can drive at least 4in/4out I2S (or probably TDM) channels (ie. 8in/8out audio channels) quite easily. Unlike most micros they don't have fixed I/O peripherals. It's a bit weird to work with (it's an extended C with some additional meta files), but if your DSP processing needs aren't too heavy, probably quite suitable. It's used in a fair number of commercial products similar to what you're proposing.

If anyone knows of any other USB AC2 demo code for other platforms I would be really excited to learn of it, as I haven't really found any, and the XMOS is really overkill for the basic applications I have been using it for.

[tszaboo]

And I2S carries playback speed, so you need precise control over it's speed, so extra hardware in the micro.

I2S carries playback speed?  So extra hardware?  How?

Yes, SCK is continuous, and DACs and other peripherals will use it to do the conversion. So it's not like SPI, that you can send a byte, wait a bit and send the next byte when ready. If your SCK has gaps or it is not exactly 32x 48 KHz, your playback is wrong.

[moffy]

The IDE's are free and good, MCUXpresso, and the development boards have SWD built in, but then the micro's all support JTAG and SWD. I've been recently using a SEEED ArchMix board (iMXRT1052) with RAM, IO pins, USB, Flash and an LCD connector and I had no problem getting the SWD working for programming etc. I used the LPC LinkII as the interface board between the IDE and the ArchMix. I too have a phobia about BGA hence the choice of an reasonably inexpensive module/board, the ArchMix.

[SiliconWizard]

I would also try to avoid using SPI for I2S emulation. It would be hard to get the timings consistent.

Not just hard, but IMO impossible. I2S is a continuous serial stream. However you try to beat up a SPI peripheral, I doubt you'll be able to do the same. Maybe with some clever programming, and if you're lucky with a given SPI peripheral allowing continuous clocking without any interruption.

[AaronD]

I would also avoid this. Generating the LRCLK with one channel of a multi-channel SPI peripheral (or divided down from your bit clock) is probably possible, and maybe you can use a PLL to generate the correct bit clock to avoid external clock generation. If using 32bit I2S it's probably not that bad, but also sounds like there's a lot of potential for gotchas and it's just another thing to waste time on niggly details. Lots of micros have I2S peripherals, or an I2S mode in their SPI peripherals. It shouldn't be hard to find something suitable, so I wouldn't consider this.

Good to know that the peripherals are more common than I've seen so far.  But of course I've been looking at the very low end of things too, so that's probably why I haven't seen them.
(there's some point in a multibyte-oriented protocol that has to be kept running constantly, on an 8-bit slow micro, but not much)

You may consider XMOS XU series devices. They are basically designed for this purpose, there is existing AC2 demo code that works well (though I wouldn't really call it 'good code'), an App Note that covers how to add basic DSP to it, and they can drive at least 4in/4out I2S (or probably TDM) channels (ie. 8in/8out audio channels) quite easily. Unlike most micros they don't have fixed I/O peripherals. It's a bit weird to work with (it's an extended C with some additional meta files), but if your DSP processing needs aren't too heavy, probably quite suitable. It's used in a fair number of commercial products similar to what you're proposing.

If anyone knows of any other USB AC2 demo code for other platforms I would be really excited to learn of it, as I haven't really found any, and the XMOS is really overkill for the basic applications I have been using it for.

Yeah, that's the overkill that I was referring to too.  My introduction to their existence was simply to connect a bidirectional TDM stream from an Analog Devices DSP, to multichannel USB.  That was it.  No DSP in the XMOS, just a dumb conversion of protocols.

Just 4 pins for TDM, assuming shared clocks for both directions, plus 2 pins for USB, plus power and a CPU clock, out of a 64-pin package!  A dedicated all-slave hardware device could probably do that with 2 power pins and no additional clock for a total of 8!  Maybe in a SOIC package?

SCK is continuous, and DACs and other peripherals will use it to do the conversion. So it's not like SPI, that you can send a byte, wait a bit and send the next byte when ready. If your SCK has gaps or it is not exactly 32x 48 KHz, your playback is wrong.

So keep it running!

Like I said before, set it up to just run constantly, regardless of any other activity.  Free-running 48kHz clock, which repeatedly triggers both the start of an exchange and another trip through the processing code.  Instead of waiting for the next data to be available, just blindly send whatever's in the buffer each time around.  If it hasn't been updated by then, the same data gets sent again.  No waiting, just run.  (that puts an absolute hard maximum on the total processing time)

Each cycle only triggers one sample's worth of activity.  The next sample requires another trigger, so the bit-clock could be set either exactly or just slightly fast so that it's guaranteed to barely finish in time.

Of course, that's all a moot point if there's a for-real I2S or TDM peripheral available.

The IDE's are free and good, MCUXpresso, and the development boards have SWD built in, but then the micro's all support JTAG and SWD. I've been recently using a SEEED ArchMix board (iMXRT1052) with RAM, IO pins, USB, Flash and an LCD connector and I had no problem getting the SWD working for programming etc. I used the LPC LinkII as the interface board between the IDE and the ArchMix. I too have a phobia about BGA hence the choice of an reasonably inexpensive module/board, the ArchMix.

I'll have a look at those too.  Thanks!

Not just hard, but IMO impossible. I2S is a continuous serial stream. However you try to beat up a SPI peripheral, I doubt you'll be able to do the same. Maybe with some clever programming, and if you're lucky with a given SPI peripheral allowing continuous clocking without any interruption.

The SPI's that I've used (admittedly on 8-bit slow micros, so there might be a difference there) have a separate buffer from the shift register.  As long as there's something new in that buffer, the SCK keeps running, so you can send a 16-bit word all at once just by writing twice and moving on.  Or you can set up an interrupt (or poll the flag) so that you keep feeding it one byte at a time while the shift register is still clocking the previous one out, and thus send a continuous stream with no interruptions.  (again, that's on an 8-bit micro with no DMA)

Likewise for receiving, that same memory address can be read to get the last complete byte received, even if there's another one in the process of coming in.  Thus, a continuous stream of input data as well, with no interruptions.

To run a continuous stream in both directions as master, just do both operations in the same "buffer-not-full" interrupt.  It's that easy.

Of course, the additional frame clock could be tricky as described above, and it's all moot anyway if there's an exact-match peripheral to use instead.

[Marco]

But if it's actually USB-standards-compliant, that shouldn't matter at all, I would think.

AFAIK only from Windows 10 is there generic async USB audio support, before that you needed custom drivers. But that won't matter for Linux.

[Bassman59]

A self-assigned background task for me is a High Speed USB Audio interface -- Audio Class 2 required -- in an ARM Cortex-M4. It's part of a larger design idea.

I've sort of given up on trying to use I2S in the micro, and instead take advantage of a micro with a external memory bus, and connect that bus to a small FPGA to manage I2S or TDM to converters as well as build in S/PDIF and ADAT ports, and even MADI. This lets me do all of the audio stuff in its own little island, with the clocking, the analog/converters, all of it decoupled from the processor. The processor just sees a port as a destination for DMA transfers.

The FPGA is the easy part. Really. A college student can do it as a senior design project. Hell, if you want, you can choose an FPGA with the resources to do DSP. (Or just buy a DSP chip with I2S, TDM and USB ...)

Digging through every vendors' USB stack is painful. NXP offers a lot of USB Audio examples, but working through the code is like chewing glass. Part of the problem is that the vendors like to give canned solutions that you add to your project, so bang! Now you have an MSC device! Just add it from the list of our middleware! I asked on NXP's forum, "what's the best way to start implementing a standard class for which you guys don't provide code?" and the answer is "start with something existing, and modify it ... " Oh, and there's always the RTOS problem.

I like the Silicon Labs USB stack. It's straightforward, and pared down: basically you get an endpoint interrupt callback and a packet of data for USB OUT endpoints or an endpoint interrupt callback saying "last packet handled!" for IN endpoints. If you read the class specs, you know what to expect and what messages you have to handle and all of it. So it's not all that hard to do an Audio Class device in their parts. I was able to get a USB MIDI device working in short order. EXCEPT they seem to have zero interest in adding a High Speed USB interface to their parts. I guess that makes sense, because their parts are all slow compared to the other vendors. (I guess the Internet Of Things That Go Bump In The Night don't need High Speed USB interfaces.)

TI's Tiva and MSP432 devices don't directly support High Speed USB, but their stack and the chips allow you to connect an external ULPI PHY and it should work. Their USB stack is more complicated than SiLabs' but manageable.

I keep thinking about looking at STM32 but haven't had the time.

Of course there's always the option: write your own USB stack! That's what they're doing with the TinyUSB project.

I suppose if you were clever and motivated and didn't otherwise have a life you could take the High-Speed USB PHY and glue it to an FPGA and do all of the stuff in the FPGA. Or maybe use a processor core in the FPGA. Or ...

Anyway, good luck.

[ve7xen]

Yeah, that's the overkill that I was referring to too.  My introduction to their existence was simply to connect a bidirectional TDM stream from an Analog Devices DSP, to multichannel USB.  That was it.  No DSP in the XMOS, just a dumb conversion of protocols.

Just 4 pins for TDM, assuming shared clocks for both directions, plus 2 pins for USB, plus power and a CPU clock, out of a 64-pin package!  A dedicated all-slave hardware device could probably do that with 2 power pins and no additional clock for a total of 8!  Maybe in a SOIC package?

'Overkill' is just going to be the reality of the situation though, I think. You're going to need USB HS, and that means a fairly beefy processor core to drive it, and those tend to come with a bunch of peripherals and whatnot. The XMOS isn't really that much more overkill than the alternatives, and it comes with ready-made AC2 code you can use to get a leg up on your end application. But it may be an overkill in 'new things to learn' as the architecture is quite different from most microcontrollers.

Your post inspired me to take a poke around at this again. It looks like NXP may have some suitable parts, I was looking at LPC5514 as a contender. Cortex M-33 core, USB HS, and up to 6 half-duplex I2S ports and 2 more that have 4 I/O ports each, also supports TDM though I've never used this mode. It also looks like the Azure RTOS includes a USB AC2 implementation, and can be used license-free on these processors... I may try this on one of their dev boards. It's quite a bit cheaper and requires less support hardware (supply rails...) than the XMOS.

Minimum viable for a dedicated IC would probably be something like a 'successor' to PCM2707, which is packaged in TQFP 32. The 'problem' is that such a trivial product isn't really viable in an end application. At a bare minimum in a typical product, you almost certainly need I2C to control your CODEC, and some code to decide what to send it and when. Such chips do exist (see CMedia CM6212 and a couple others, which is an 8051 core strapped to a USB-I2S converter), but you can't really buy them and there is no documentation or code available. If you have a volume product in mind though it might be an option.

[Bassman59]

Your post inspired me to take a poke around at this again. It looks like NXP may have some suitable parts, I was looking at LPC5514 as a contender. Cortex M-33 core, USB HS, and up to 6 half-duplex I2S ports and 2 more that have 4 I/O ports each, also supports TDM though I've never used this mode. It also looks like the Azure RTOS includes a USB AC2 implementation, and can be used license-free on these processors... I may try this on one of their dev boards. It's quite a bit cheaper and requires less support hardware (supply rails...) than the XMOS.

I'm looking at the LPC5528, same thing as the 5514 but without CAN. I like how the FLEXCOMMs are all identical and you just configure each for the mode you need. (Unlike TI TM4C1294 which for some reason has ten I2C ports!)

re: Azure RTOS, looking at the Github I see for a demo they have descriptors which are just lists of hex bytes, as opposed to some of the crazy macros and defines you see everywhere else.

Minimum viable for a dedicated IC would probably be something like a 'successor' to PCM2707, which is packaged in TQFP 32. The 'problem' is that such a trivial product isn't really viable in an end application. At a bare minimum in a typical product, you almost certainly need I2C to control your CODEC, and some code to decide what to send it and when. Such chips do exist (see CMedia CM6212 and a couple others, which is an 8051 core strapped to a USB-I2S converter), but you can't really buy them and there is no documentation or code available. If you have a volume product in mind though it might be an option.

TI has shown no interest in a High Speed follow-on to the PCM27xx devices.

[ve7xen]

I'm looking at the LPC5528, same thing as the 5514 but without CAN. I like how the FLEXCOMMs are all identical and you just configure each for the mode you need. (Unlike TI TM4C1294 which for some reason has ten I2C ports!)

re: Azure RTOS, looking at the Github I see for a demo they have descriptors which are just lists of hex bytes, as opposed to some of the crazy macros and defines you see everywhere else.

I ordered the LCP55S28 devboard and will give this a shot. I also noticed that the NXP 'MCUXpresso' SDK includes USB Audio Class 2 support, so that might be a winner too, as it looks a little more fleshed out with examples and such than the Azure code. I'll probably start there, it's also all under a BSD-3 Clause license, including the examples, which is much more permissive than the Microsoft license.

Wish I found this earlier.

[moffy]

I'm looking at the LPC5528, same thing as the 5514 but without CAN. I like how the FLEXCOMMs are all identical and you just configure each for the mode you need. (Unlike TI TM4C1294 which for some reason has ten I2C ports!)

re: Azure RTOS, looking at the Github I see for a demo they have descriptors which are just lists of hex bytes, as opposed to some of the crazy macros and defines you see everywhere else.

I ordered the LCP55S28 devboard and will give this a shot. I also noticed that the NXP 'MCUXpresso' SDK includes USB Audio Class 2 support, so that might be a winner too, as it looks a little more fleshed out with examples and such than the Azure code. I'll probably start there, it's also all under a BSD-3 Clause license, including the examples, which is much more permissive than the Microsoft license.

Wish I found this earlier.

Let us know how you get on, a USB Audio class 2.0 solution would be interesting. Pity about Windows 10 though not supporting class 2.0.

[SiliconWizard]

Pity about Windows 10 though not supporting class 2.0.

It does since Windows 10 1703, which is like 4 years old.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

[moffy]

Pity about Windows 10 though not supporting class 2.0.

It does since Windows 10 1703, which is like 4 years old.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

Thanks for the info. Is the fact that it is WaveRT the reason XMOS require their own custom driver for Windows 10?

[SiliconWizard]

Pity about Windows 10 though not supporting class 2.0.

It does since Windows 10 1703, which is like 4 years old.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

Thanks for the info. Is the fact that it is WaveRT the reason XMOS require their own custom driver for Windows 10?

I frankly don't know. It took so long for Windows to finally get USB audio 2.0 that vendors had their own drivers for their audio interfaces anyway. The XMOS solution for instance is much older than 4 years. And then they keep distributing their drivers even for Windows 10 just so people are able to use the device on *any* version of Windows 10.

Additionally, they may have implemented some specific features in their own drivers compared to the generic one, but I do not know.

[Bassman59]

Pity about Windows 10 though not supporting class 2.0.

It does since Windows 10 1703, which is like 4 years old.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

Thanks for the info. Is the fact that it is WaveRT the reason XMOS require their own custom driver for Windows 10?

I frankly don't know. It took so long for Windows to finally get USB audio 2.0 that vendors had their own drivers for their audio interfaces anyway. The XMOS solution for instance is much older than 4 years. And then they keep distributing their drivers even for Windows 10 just so people are able to use the device on *any* version of Windows 10.

Additionally, they may have implemented some specific features in their own drivers compared to the generic one, but I do not know.

The XMOS developer kit implementation of USB Audio Class 2.0 does nothing particularly special that requires a non-generic Class driver. It has been well-supported in macOS for, oh, FIFTEEN YEARS now. I did test that hardware on an up-to-date Windows 10 machine without the custom XMOS driver and it worked as expected.

[Bassman59]

I'm looking at the LPC5528, same thing as the 5514 but without CAN. I like how the FLEXCOMMs are all identical and you just configure each for the mode you need. (Unlike TI TM4C1294 which for some reason has ten I2C ports!)

re: Azure RTOS, looking at the Github I see for a demo they have descriptors which are just lists of hex bytes, as opposed to some of the crazy macros and defines you see everywhere else.

I ordered the LCP55S28 devboard and will give this a shot. I also noticed that the NXP 'MCUXpresso' SDK includes USB Audio Class 2 support, so that might be a winner too, as it looks a little more fleshed out with examples and such than the Azure code. I'll probably start there, it's also all under a BSD-3 Clause license, including the examples, which is much more permissive than the Microsoft license.

Wish I found this earlier.

I have that same board, as well as the LPC54628 which adds 10/100 Ethernet.

Good luck unraveling that spaghetti code.

[SiliconWizard]

Pity about Windows 10 though not supporting class 2.0.

It does since Windows 10 1703, which is like 4 years old.
https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

Thanks for the info. Is the fact that it is WaveRT the reason XMOS require their own custom driver for Windows 10?

I frankly don't know. It took so long for Windows to finally get USB audio 2.0 that vendors had their own drivers for their audio interfaces anyway. The XMOS solution for instance is much older than 4 years. And then they keep distributing their drivers even for Windows 10 just so people are able to use the device on *any* version of Windows 10.

Additionally, they may have implemented some specific features in their own drivers compared to the generic one, but I do not know.

The XMOS developer kit implementation of USB Audio Class 2.0 does nothing particularly special that requires a non-generic Class driver. It has been well-supported in macOS for, oh, FIFTEEN YEARS now. I did test that hardware on an up-to-date Windows 10 machine without the custom XMOS driver and it worked as expected.

Okay, so the reason is probably just my first point.
And yes, USB Audio Class 2.0 has been supported both on MacOS and Linux for a MUCH longer time than on Windows. Maybe a "market" they didn't care about, or maybe they also just didn't dislike the fact all vendors had to pay for getting their drivers certified...

[moffy]

Thanks for the info, it's encouraging to know that you can use the XMOS audio without their proprietary driver. Interesting observation from Microsoft:
"This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft." The same people that developed the XMOS driver.

[SiliconWizard]

Of course there's always the option: write your own USB stack! That's what they're doing with the TinyUSB project.

I had taken a brief look at it, but not done anything yet with it. Do you have any reason not to consider it?

https://github.com/hathach/tinyusb