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!

[waclawek.jan]

Do you intend to transfer DSD over USB, or you just want to transfer PCM and convert it to DSD/PDM in the 'F7?

JW

[Moreno1]

I want to have USB Audio Class 2 providing samples directly to the port, without manipulation or conversion. So I want to transfer DSD over USB.

If a SAI port cannot be modified to do so, one approach I thought about is using the QuadSPI port to output signals - it has multiple data lines and a fast enough clock. I could port the UAC2 to get the usb samples and handle them via DMA to the SPI port.

Do you think this is a feasible approach?

Regards

[waclawek.jan]

IMO QSPI is not very suitable for the task, as most of its working is hardwired to support the sFLASH memories. OTOH, I don't see an immediate reason why SAI would not be good enough.

The tricky part might be handling of data. If I understand it correctly, DSD data arrive as the lowermost 16-bit in 24-bit frames, with channels following the native audio channels arrangement (i.e. for stereo, alternating left-right 24-bit frames). In other words, data you'd be pulling from USB's FIFO (or from RAM if you think using DMA in USB will help), you'd need to take apart to 24-bit chunks, and feed those to two SAI channels alternately. There's definitively processor work involved, and IMO that's hard to estimate and would need some proof-of-concept kind of benchmarking...

Sounds interesting! :)

JW

[MikeDB]

Yes ditch the XMOS and use a STM32F730. They are so cheap and powerful they make the idea audio processor for uses far more powerful than you describe. I'm building an audio array processor of them and on paper it outperforms DSP based solutions. Hopefully reality will match paper.

[Moreno1]

Your understanding is correct for DSD over PCM, which encapsulates the DSD data over a 24bit PCM stream over USB. This would require repacking the data.

If you use DSD Native, you don't need to encapsulate the data into the PCM stream, you can read it directly coming from the driver. However, you need the driver to be able to shoot a DSD stream for you, which is a project in itself. This removes the overhead and allows faster data rate at the receiver end (in this case the STM32F7 chip).

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, which can go from 2.8224MHz (DSD64) until 22.5792MHz (DSD512). I'm not sure if the SAI port can handle a clock this high frequency while switching the sample bit. That is why I proposed the QuadSPI or even the Dual SPI port. I need separate L/R signals with a very high bit clock.

Any pointers on which port of the STM32F7 could do this? I'm in the design phase and I will be doing sch and layout, so it is an interesting phase of the project to make changes and try new things.

Thanks for the interest in the my project.

[MikeDB · Accepted solution]

I might be missing something in the detail, but the SAI port can go to 24.576MHz which seems to be enough for your application. If that isn't fast enough could you put some simple logic to split the L&R signals and feed them into separate SAI modules ?

[Moreno1]

Hello and thank you for your answer! I was not aware the SAI port can go that fast. Is that the frequency of the MCLK out or the BCLK signal? It will take some external muxing to do the interface, but I think I can use a sync'ed slave channel in transmit mode for the split L/R channel.

This is quite exciting, I will submerge myself into the reference manual and see how I can interface this to my CODEC.

Thank you so much

[MikeDB]

Hi - the SAI_MCK goes to 256*192kHz whilst the SAI_CK goes to 128*192kHz.

Page 179 of the 201 page version of the datasheet. In fact I suspect the hardware can go much faster as the SPI it shares a lot of hardware with goes much faster, but obviously STM haven't heard of 384kHz sampling ?

I thought you were taking DSD in and converting to PCM for the CODEC but sounds like this is not the case if you are transmitted DSD. I assumed you were just receiving. For TX I bet you can run an SPI port to much higher frequency and meet the DSD spec.

Whilst CODEC are you using ?

[Moreno1]

I will be using the AK4493EQ from AKM, which has DSD functionality. So the data flow will be:

USB Audio Class 2 (on Linux, Mac and Windows with driver) -> USB -> SAI -> Codec

If I only play native PCM or native DSD, then I believe the limitations are:

• Port speed
• 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

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. I suspect that I can support some of the DoP cases with the 216MHz part, but not the 22MHz one.