ADCs and DACs for audio instrumentation applications

For I2S output the crystals provide the SAI clock for the MCU which generates the I2S signals (BCK, SD and LRCK). MCK out is divided from the crystal . For I2S input the board acts as a slave.

Can the slaved I2S input be mastered by bit/frameclock signals generated by the I2S output? I mean the standard duplex operation with DAC and ADC running in sync. Thanks.
 
I was merely trying to give my advice on what I think is the best clock concept for a USB interface. Feel free to disagree and design it the way you want.

Thanks for the advice. I do not disagree with that. However you seem to not fully understand how STM32F7 SAI works. My objective was not to build the best possible USBI2S bridge but to build a STM32F7 based one.
 
Can the slaved I2S input be mastered by bit/frameclock signals generated by the I2S output? I mean the standard duplex operation with DAC and ADC running in sync. Thanks.

That should be possible as both I2S input and output are running on the same SAI. But I have not tried it yet as the I2S input software is still work-in-progress.

Actually syncing is possible even between separate SAIs.
 
Last edited:
Member
Joined 2009
Paid Member
Thanks for the advice. I do not disagree with that. However you seem to not fully understand how STM32F7 SAI works. My objective was not to build the best possible USBI2S bridge but to build a STM32F7 based one.
You are correct, I don't know how the STM32F7 SAI works. I just assumed that there is another clock to run the processor and the USB, with audio clocks being separate and selectable. There seems to be 3 crystal oscillators on your design.

Are the DAC and ADC clocked by the same master clock?
Yes, they are clocked by the same master clock. I once made a similar test, where I used two units, one as the generator and one as the analyzer. The result was very similar, if not the same, compared to using one unit in loopback mode. It may have been with a 10 kHz sine wave though, not the jtest.
 
I just assumed that there is another clock to run the processor and the USB, with audio clocks being separate and selectable. There seems to be 3 crystal oscillators on your design.

Actually there are 4 oscillators (25MHz & 32.768kHz for the MCU).
STM32F7 (as probably most Cortex-M MCUs) can generate the I2S clock using PLL. However this results in slight inaccuracy in the frequencies as the PLL is integer based. The "audiophile" approach is to input the audio clock to a GPIO pin which results in accurate frequencies (and possibly lower jitter). The SAI (Serial Audio Interface) uses this audio clock to generate the actual I2S signals (BCK, SD, LRCK and possibly MCK).

I fail to see how placing the audio input clocks outside the isolator would improve jitter in this case as the actual I2S signals will anyhow need to go through an isolator. The MCK may have less jitter but does that really help.
 
The SAI of STM32F7 is certainly very flexible, allowing all modes of operation, including the external clock behind the isolator, IMO. The chip looks like a perfect fit for this feature :) Of course another criterum is quality of the UAC2 device implementation which I have no idea about.

The USB implementation of STM32F7 (or F2-H7) is based on Synopsys OTG controller. This is largely (if not totally) undocumented so in that sense the STM32F7 USB is a black-box. The HAL-part is just a thin layer on top of the Synopsys OTG. But so far I have not stumbled on anything seriously bad about the STM32F7 USB implementation. I assume even 768k/32 is possible but I have not yet tried that.
 
I fail to see how placing the audio input clocks outside the isolator would improve jitter in this case as the actual I2S signals will anyhow need to go through an isolator. The MCK may have less jitter but does that really help.

In cases where I2S signal jitter may be a concern, if the master clock is on the dac side of the isolators then the master clock can be used to 'reclock' or 're-synchronize' the I2S signals through a D-Flip Flop buffer. For that to work correctly the master clock frequency needs to be at least twice that of the highest I2S clock frequency (otherwise the flip-flops can act as frequency dividers).
 
Well, one thing is the OTG controller, another thing is the UAC2 implementation. It's the same in linux - the dwc2/3 Synopsys controllers have drivers (with bugs as everything) and each USB device function (uac2, ethernet, mass storage etc.) has its driver (with another load of issues often related to support of drivers in major OSes).

The Synopsys IP implementations differ in each SoC, the documentation quality differs too. Fortunately dedicated Synopsys engineers with inside know-how actively participate in the kernel mailinglists and constantly review or provide patches for dwc2/3. I have only experience with dwc2 in RPi4 and the dwc2 Synopsys engineer has been extremely helpful with ironing out issues. He does have access to dwc2 IP implementation in the Broadcom SoC, sometimes even sent me fragments of their PDFs.
 
In cases where I2S signal jitter may be a concern, if the master clock is on the dac side of the isolators then the master clock can be used to 'reclock' or 're-synchronize' the I2S signals through a D-Flip Flop buffer. For that to work correctly the master clock frequency needs to be at least twice that of the highest I2S clock frequency (otherwise the flip-flops can act as frequency dividers).

I2S reclocked with master clock after optocouplers and phase noise plot:
- blue line, masterclock
- pink line, reclocked BCK
- green line, reclocked LRCK
 

Attachments

  • TWSAFB-OIR.jpg
    TWSAFB-OIR.jpg
    319 KB · Views: 181
  • I2S reclock with master clock.png
    I2S reclock with master clock.png
    156 KB · Views: 200