STM32F4xx/F7xx: USB to I2C interfacing for audio play/record

[PaulQ]

Hallo, I cannot find any guideline on how to use the I2S and USB peripheral in order to interface PCs and Mac to I2C D/A and A/D converters. Talking about USB asynchronous with speeds up to 384LB/s. These boards are nowadays designed with specialised FPGA or with ATMEL CPU. Surely this can be done with an F4 or F7, but I cannot fina app notes or sample projects. Any hint ?

[MikeDB]

Yes a F4/F7/H7 can do this easily, and even do things like effects, tone controls, graphic equaliser or anything else you want as well.

Firstly most A-D and D-A convertors are I2S, not I2C compatible. You can wire a typical audio codec such as AK4556 directly to the F4/F7/H7 I2S pins. I'd then create a program to generate a simple sinewave and write it into the DMA buffer and drive the D-A part from the DMA controller so that you sort all the clocks out. Then loopback the audio to the A-D convertor and check you are getting a sinewave back.

Only then move onto the USB part. This will depend on how you are encoding the audio on the USB as there are several standards. But there are lots of USB libraries I am sure you can adapt.

[PaulQ]

Sorry my auto-corrector always puts I2C instead of I2S ... :flushed_face: I meant I2S obviously.

My concerns are about the so-called bit perfect, with can be achieved with asynchronous audio USB.

If I well understood, this involves creating an additional endpoint to communicate with "generator", in order to slow down/speed up data rate and not to over/underbuffer.

This is one difficult point, the other is to be sure of the low jitter and high precision of I2S peripheral + firmware.

Furthermore, the USB libraries adopted in commercial/diy project with other processors don't need specialised driver, the interface (and the asynchronous feature) should be recognised and be available automatically.

So, precision of I2S interface and performance of USB driver are essentials features...

[MikeDB]

Ok I'll answer in reverse. The DMA controllers and SAI interfaces (set to I2S) on the H series have no noticable jitter so the F series should be fine as well. So the only task is to ensure you keep the buffers about half filled.

Bitperfect is just a marketing term - which audio transport scheme are you using ?

Also where is the master sampling clock - in your F series or at the other end of the USB cable ? One has to slave to the other no matter what you do otherwise you'll have under/over-run, or will need to do sample rate correction (not nice !).

[PaulQ]

I'm taking https://www.electronicdesign.com/embedded/achieving-bit-perfect-usb-audio as an example. For D/A section it seems that Asynchronous Mode with local high-precision clock allows best data transfer between PC/MAC and device, without data loss or interpolation needs (that are absolutely prohibited in high end audio). In this case I2S peripheral should be clocked by an high precision oscillator, while STM32F4 should/could use standard 8...24MHz crystal for internal and USB clocking.

On A/D side, I think that I2S generates master clock to control converter, and then streams data to PC/MAC (I don't know the USB details here).

[MikeDB]

Well remember the audio has sometimes been interpolated once or twice before it got to you, but yes async mode is what I would use as well. This means the PC is slaved to the D-A convertor by the return correction signal. The article seems to tell you most of what you need to implement, although I doubt you will find the USB feedback arrangement in the library (but I haven't looked) so will have to write that yourself. However it is fairly trivial at the STM32 end - the hard part will be the PC driver.

[PaulQ]

For sure audio will be interpolated before being sent out to usb (e.g. upsampled to 96KHz). What I'm concerned about is

• quality and low jitter of a USB->I2S implementation, for example I think that STM32F4 internal PLL is a very good jitter generator....;
• Feasibility of inverse (I2S->USB) implementation, this is by far less common;
• Drivers: should be standard

Most (if not all) USB->I2S interface on the market don't require special drivers...

As an example, here

https://github.com/jmf13/USB_Async_DAC/tree/CleanerCode/USB_Audio_Async

one can find an async example (only DAC). Before start do dig into code, anyway, I would be sure not to run into a real dead end.

[MikeDB]

If the STM32 clock was slaved to the USB incoming clock then jitter could be a problem. But as you are using aynch mode with feedback then the PLL simply locks onto the local crystal and will be rock solid. I really wouldn't worry about this part.

Likewise for ADC, the fact you are using the local clock means this will also be solid. The only problem would occur if the PC at the other end of the cable could not take the data in time. The trade off here is what latency (delay) you can accept in the system which determines the maximum buffer size you should implement on the ADC side.

I was remembering Cambridge Audio always claimed their USB driver was better than the standard ones. But if standard ones are fine nowadays then again you have even less to worry about.

And as you've found what looks like a good code source to base your design on, I think you're 90% there.

But if you really are worried about jitter being a problem, put the pads for a CS2200 on your PCB just in case it is needed. But I really don't think it will end up being used.