Skip to main content
Moreno1
Moreno1
Associate
February 14, 2019
Solved

Using STM32F7 for USB Audio and HiRes Audio (DSD)

  • February 14, 2019
  • 4 replies
  • 6494 views

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!

This topic has been closed for replies.
Best answer by MikeDB

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 ?

4 replies

waclawek.jan
waclawek.jan
Super User
February 15, 2019

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
Moreno1Author
Associate
February 15, 2019

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
waclawek.jan
Super User
February 15, 2019

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

Moreno1
Moreno1Author
Associate
February 19, 2019

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
MikeDBBest answer
Senior II
February 19, 2019

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 ?

MikeDB
MikeDB
Senior II
February 16, 2019

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.

waclawek.jan
waclawek.jan
Super User
February 19, 2019

> 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

Terms & ConditionsAccessibility statement