Using STM32F7 for USB Audio and HiRes Audio (DSD)

[Moreno1]

I'm looking for the appropriate MCU to include as a main processing unit in a DAC product I'm designing. The product uses an XMOS for USB Audio and is in need for a central CPU with a more approachable programming model. I came around choosing between F4 and F7, because along with user interface tasks and housekeeping, the MCU will have to handle the SPDIF/RX signal input - I'm not keen on adding S/PDIF routing into XMOS I2S routines.

I understand the F7 is substantially more powerful than the F4, so this begs the question: can I ditch the XMOS altogether and port the USB Audio Class to the F7? I mean does this part have the processing power to keep up with an audio signal that is 192k/32b?

Another tricky one: the SAI port on the F7 does not support DSD, which in it's faster iterations can go up to 11MHz on the output. Do you think it is possible to output that sort of signal out of an F7? Some designs out there use CPLDs connected to the CPU to achieve DSD, would that be the case here?

I appreciate any input on the questions here, or any interest in my project.

Thanks!

[MikeDB]

Well right brand of convertors :) But I've not been convinced by 11MHz DSD so have stuck with PCM to date, but maybe at 22MHz it might make me reconsider.

Currently designing with the AK5388A A-D convertor followed by a H750 which with a few tricks gives virtually as good as it can get for microphone digitization.

[waclawek.jan]

> The problem I see with the SAI is that a DSD waveform is comprised of L / R signal, which are switched at the DSD bit rate,

You mean, both channels bit-interlaced onto a single data lane, as the MEMS microphones do? There's no hardware in the STM32 to do that and there's no way software could keep up doing this.

Hoever, it's not how the AK4493 apears to be expecting data, having separate DSDL/DSDR pins, so I expect this could be handled relatively easily. That's what you referring to by saying

> On the other hand, if I decide to support DSD over PCM (DoP), I might have to unpack the 16 bits of

> the DSD signal, form the datagram for the CODEC and shift it out through the existing DSD port

> implementation. This is very low overhead, as it's basically passing samples around.

Correct?

So then what you probably do is configure SAI to have both channels synchronized; take the incoming L/R 24-bit stream, strip out the 16-bit value for L, put it into buffer for channel A; from the next 24-bits strip out 16 bits into buffer for channel B; and have two DMAs run to fill the channels while they churn out the bits.

> Pin configuration, as DSD pins and PCM pins on the AK4493 are the same, I might have to use some multiplexing to come around this problem

MCLK is always connected to SAIx_MCLKy, BICK/DCLK is always connected to SAIx_SCKy and SDATA_DSDL to SAIx_SDy. The only pin which changes role is LRCK/DSDR, as LRCK connects to SAIx_FSy and DSDR to SAIx_SDz. But given they don't function at the same time, I would simply connect hard SAIx_FSy and SAIx_SDz together (and to LRCK/DSDR), and configure the currently unused on as GPIO input.

As I've said, I'd benchmark, using a cheap Nucleo or maybe perhaps the somewhat more expensive 'F723 Disco (as the 'F723 is the only STM32 with built-in HS-PHY) or the 'F746-DISCO (with external HS-PHY). I'd start with a fixed array of data in memory representing the 24-bit stream from USB, and would try to get the SAI working, observing output pins with a LA. Then, if I'd be confident I could cope with the data stream and familiar with the various memories' and caches' quirks, I'd move on and have a look at the OTG-HS, which is also a quirky beast and I recommend to have a good look at the "divers" offering.

Yes, sounds lots of fun.

JW