Audio streaming clock sync

[ajgboomer]

Posted on February 13, 2013 at 17:00

I am interested in techniques for synchronizing the STMF4 I2S clock with an incoming audio stream on the USB. The clock on the source and the clock on the STM32 board will always be slightly out of sync causing either its DMA to the codec to be ahead or behind the stream. Dropping / stuffing samples or re-sampling the stream are not preferred solutions.

Thanks, Tony #stm32f4-i2s #streaming

[Tesla DeLorean]

Posted on February 13, 2013 at 18:03

Use a steerable clock source for the codec, and discipline it.

Use a DDS/NCO as the clock source, tune it.

[ajgboomer]

Posted on February 13, 2013 at 19:21

Hello Clive1,

Thanks for that suggestion. I was hoping for a solution that would exist within the bounds of Stm4f, like changing the 12s clock divider ratio in real time. From the spec sheet, this does not seem possible. Regards, AjG

[Tesla DeLorean]

Posted on February 13, 2013 at 19:37

I'm not even sure how you're going to do time transfer from the PC using USB, it's not as if it's even synchronous with the audio sampling, it's just a high rate burst transport.

The only way I can see that you're going to control the sample rate is to goose the phase/duty of the bit clock, introducing through nanosecond jitter to advance or retard the clock bias to account for the clock drift. All in all a bit of a bugger if you don't share a common clock, or use PPB clock sources at each end. ie a Telco like solution I've always lamented the lack of NCO's (phase accumulators) and the use of stupid integer dividers in a chip designed in the 2010's

[lowpowermcu]

Posted on February 14, 2013 at 09:00

Hi ajg & Clive,

I am intereseted in such application... In the reference manual RM0033, it is mentioned ''

The OTG FS core provides means to monitor, track and configure SOF framing in the host

and peripheral, as well as an SOF pulse output connectivity feature. Such utilities are especially useful for adaptive audio clock generation techniques, where the audio peripheral needs to synchronize to the isochronous stream provided by the PC, or the host needs to trim its framing rate according to the requirements of the audio peripheral. ...... An SOF pulse signal, generated at any SOF starting token and with a width of 12 system clock cycles, can be made available externally on the SOF pin using the SOFOUTEN bit in the global control and configuration register. The SOF pulse is also internally connected to the input trigger of timer 2 (TIM2), so that the input capture feature, the output compare feature and the timer can be triggered by the SOF pulse. The TIM2 connection is enabled through the ITR1_RMP bits of TIM2_OR register''

According to what mentioned above, the desynchro between host and device can

be measurured using TIM2. And we know that the I2S has an error of 0.0186% @ 48 KHz (Table 100. Audio frequency precision)

@Clive, so theorically we can predict the loss of synchro (if we neglict the jitter), isn't it?

Is there another parameter to take into account (other than delay between host and device, I2S clock error)? And what could be the formula to be used for measuring desynchro??????

[tsuneo]

Posted on February 14, 2013 at 12:12

Hi everyone,

USB Audio class (UAC) defines three types of synchronization method, 1) Synchronous  - bus clock (ie. SOF timing) is the master sampling clock 2) Asynchronous - Device has the master sampling clock 3) Adaptive - Host has the master sampling clock These sync types are declared at the endpoint descriptor of the bmAttributes field of the isoc endpoint 1) Synchronous The device applies PLL to generate local sampling clock for the codec, synchronized to SOF timing. As lowpowermcu said, A timer, gated (captured) by SOF trigger, is available to configure PLL with firmware aid. In this method, the isoc endpoint exchanges a fixed number of samples. It makes the firmware simple. 2) Asynchronous The sampling clock on the device is fed back (or forward) to host. For Audio Sink device (such as a speaker) device, a feedback endpoint, associated to the isoc EP, sends feedback data to host. To generate feedback data, A timer gated by SOF trigger is also used, because feedback is calculated relative to SOF timing. For Audio Source device (such as a microphone), variation of the sample number in each isoc transaction represents fractional ratio of device sampling clock and SOF timing. For example of 96kHz sampling, each isoc transaction usually sends 96 samples. 97 samples at one transaction every 10 transaction means 96.1 kHz, relative to SOF timing. In this case also, a timer (counter) gated by SOF is used to determine the number of samples on current transaction. 3) Adaptive The sampling clock on host is notified to the device. For Audio Sink device, variation of the number of samples represents the master clock frequency relative to SOF timing, like above Asynchronous Source. A PLL recovers the clock frequency using sample number of each transaction and SOF timing. For Audio Source device, a feedback endpoint supplies the ratio of sampling clock, relative to SOF, to the device. Again, a PLL is applied to recover the sampling clock. In every method, SOF trigger to a timer is inevitable for USB Audio application. Tsuneo

[ajgboomer]

Posted on February 14, 2013 at 12:43

Hi chinzei.tsuneo,

I agree the timer is handy for determining the clock drift. If one knows the drift, can it be applied to the I2SC clock divider chain in real time? I thought that once the clock was running, the divider chain parameters could not be changed. Regards, AjG

[Tesla DeLorean]

Posted on February 14, 2013 at 12:56

Absent a control of frequency you have to stuff/remove a sample periodically as drift accumulates (bias)

[ajgboomer]

Posted on February 14, 2013 at 13:28

Agree. It is looking like the only way using just Stm32 resources (sigh).

[tsuneo]

Posted on February 14, 2013 at 15:05

> I agree the timer is handy for determining the clock drift. If one knows the drift, can it be applied to the I2SC clock divider chain in real time?

Did you consider on the time scale of this ''real time''? In USB Audio sense, the time scale is 10 ms order. It is the reason why firmware-aided PLL makes sense. Tsuneo