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**.
(*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.)
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!