I will switch to the STM32F7 as soon as you will release your UAC2 code to the public domain 😀.
Meantime, I do not have the time and mood to write an UAC2 stack for the STM myself, so I have to rely on what exists. For mere mortals like myself I don't see anything beyond the XMOS and the now obsolete CM6531. Any other options (like the new CM6635, ComTrue, etc...) are beyond my DIY reach.
Meantime, I do not have the time and mood to write an UAC2 stack for the STM myself, so I have to rely on what exists. For mere mortals like myself I don't see anything beyond the XMOS and the now obsolete CM6531. Any other options (like the new CM6635, ComTrue, etc...) are beyond my DIY reach.
Its conceivable that the sources can share ground, unless you want to use the Boonton trick to get 16V RMS, essentially a bridge tied load for the output. That would require two isolated outputs. The inputs can be a common ground with differential inputs. They would need good CMRR.
This is another path for USB : The ζ1 Audio Widget asynchronous USB-I2S module Open-source USB interface: Audio Widget . It originated as a ham project for recording SDR stuff. The code etc. is open and you can get one to play with. I have an extra somewhere I can send.
I have not seen any open source stuff other than TinyUSB (which is not async). I wrote mine based on the UAC1 examples STM provides.
Unfortunately porting that code to STM32 is probably more difficult than starting from scratch.
I agree as the critical built-in functionality of STM32 MCUs (e.g. SAI) is totally different. Some of the higher level stuff may be of interest. My sync FB scheme originates from SDR widget.
STM32F7 isn't cheap, especially today, also the current draw should be noticeable higher vs state machine + 8051 that typically we can find in a UAC2 bridge. Cmedia seems has no plans to give the source-code anymore, savitech has even more hermetic policy. That way, I keep using Comtrue. Huh, last time Comtrue gave me 4 new PIDs for my products, I tested that, looks ok, however, Comtrue's programming tool can't detect these new PID at all.. I asked Comtrue about that a few times(they don't like to replay fast if your question is not about "how to buy") what a hell is this? They said - we have no such problem on our side. Kind of "be happy" ))
So, an ideal USB audio solution doesn't exist, maybe Ti or Analog bridge with open source code would be a good candidate.
So, an ideal USB audio solution doesn't exist, maybe Ti or Analog bridge with open source code would be a good candidate.
Yes, STM32F7s are not cheap and currently sold out everywhere. But as a purely hobbyist price of the MCU is not a prime concern to me. STM32F7 has much lower power consumption compared to XMOS and it can be used for various other chores than just UAC. And I really like the STM32 toolset which is also free of license charges.
XMOS eats like a horse indeed but STM32F7 will have rather comparable with XMOS current than state machine + small MCU.
I dodn't measure the power used by my UAC2 implementation on a LPC4330, but it used a tiny amount of CPU, a few percent on the Cortex-M4. So the power used by the CPU would be very low. It's all DMA, the CPU does not touch the data.
For multichannel though, that damn SGPIO peripheral required the cortex-M0 to move each sample in software. So that would be a problem.
However if someone can find a chip with multichannel I2S with DMA that actually works, then the CPU should do almost nothing while playing. In that case, CPU requirements are way below Cortex-M7. In fact you could probably underclock it to a ridiculously low frequency.
Of course the ideal solution for power and noise would be a small FPGA with an USB core, but that's a lot more complicated.
For multichannel though, that damn SGPIO peripheral required the cortex-M0 to move each sample in software. So that would be a problem.
However if someone can find a chip with multichannel I2S with DMA that actually works, then the CPU should do almost nothing while playing. In that case, CPU requirements are way below Cortex-M7. In fact you could probably underclock it to a ridiculously low frequency.
Of course the ideal solution for power and noise would be a small FPGA with an USB core, but that's a lot more complicated.
STM32F7 has 2 SAIs with DMA so it is possible to have 8-channels with DMA. Whether or not the CPU needs to touch the samples depends on the application.
Can the SAI do 384 kHz or higher? Last I checked their HAL had limited you to 192 kHz. I assume if you modify it the hardware could probably do more since it’s similar to the SPI peripherals.
I have not tried above 192k since the F723Disco board does not allow external I2S clocking. I believe PLL-based SAI is limited to 192k but 384k (or even 768k) may be possible with external I2S clock. I will test it as soon as my usb-to-i2s bridge is ready.
I have tried a Nucleo-144 board with 24.576MHz external I2S clock and no MCK divider. The SAI outputs 384kHz FS and 24.576MHz SCK which is correct for 384k. However the Nucleo board does not have HS-support so no real testing is possible.
I have tried a Nucleo-144 board with 24.576MHz external I2S clock and no MCK divider. The SAI outputs 384kHz FS and 24.576MHz SCK which is correct for 384k. However the Nucleo board does not have HS-support so no real testing is possible.
Last edited:
Sorry, spoke too soon 😀 I tried F7Disco PLL-SAI@384k and it seems to work (i.e. SAI keeps up with the pace). However no real testing is possible since wm8994 on the F7Disco is limited to 96k (and I do not want to butcher the board yet).
At the other end: MS maximal 384kHz SR, if more you need (or DSD native) to use ASIO and related MS ASIO driver validated by
The ST HAL is almost always the bottleneck, in any application that requires high speed. A certain performance hit is to be expected for any HAL implementation, but ST went IMO way too far in dumbing down their HAL at a hefty performance cost. To the point it is good only for demo code.