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

[lowpowermcu]

Posted on February 14, 2013 at 15:45

Hi chinzei,

Theorically we can predict the loss of synchro using:   - TIM2 SOF to measure the delay between host and device   - static I2S error (lets say 0.038%)    if we neglict the jitter, is the loss of synchro predicatable? 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 15:57

> Theorically we can predict the loss of synchro using:

You don't need to predict, just give feedback to the host in ''real time'', so that host synchronizes to your device. What is your device, Sink (speaker) or Source (Microphone)? Tsuneo

[lowpowermcu]

Posted on February 14, 2013 at 16:08

Hi tsuneo,

I am in case of Sink (speaker).just give feedback to the host in ''real time'' But If I have well understood I have to say that in next frame I will ask the host to send 127 samples and not 128 samples so I need to ''predict'' when I have to ask only 127 samples. I mean by prediction that due to loss of synchro I have to ask 127 samples after heving received 100 times128 samples. I hope I am clear.

[tsuneo]

Posted on February 14, 2013 at 18:48

For Synchronous Sink, your device have plenty of time to synchronize to SOF, before audio streaming starts on the isoc endpoint. SOF packets are sent to the device at the beginning of device connection (SOF starts just after bus reset, before enumeration starts).

For Asynchronous Sink, your device also has plenty of time to calculate feedback. The local ''master'' sampling clock is fed to a timer as its clock source. SOF trigger captures this timer value. mean of 8 (or more) captures generates 10.10 format of feedback. You may start this feedback calculation process at any time after connection, to provide stable feedback. For Adaptive Sink, the sampling frequency is given as the number of samples on packets. Therefore, the packets received on the isoc OUT endpoint are put to a buffer first. This buffer holds 10 or more packets, before the sample data are sent to I2S (or DAC). Summing up these number of sample data, your device tunes the PLL. Of course, this buffer causes internal delay. Such delay is shown in the bDelay field of Class-Specific AudioStreaming Interface Descriptor in number of frames. Anyway, your audio device should declare one of synchronization method on the endpoint descriptor. In this point also, ST's audio example is wrong. Tsuneo

[lowpowermcu]

Posted on February 14, 2013 at 19:46

Hi tsuneo,

Let's take the case of asynchronous mode and audio frequency is 48 KHz: if the TIM2 measures a desynchronization of 50 µs over 1 second so 50 µs * 48000 = 2.4 samples over 1 second and I am using 6 buffers of 192 samples (USB sends 192 samples per 1 ms) so my buffers are 1152 samples which is equivalent to 6 ms long overrun/underrun occurs when read pointer and write pointer overlaps and this happens when distance between pointers is the half size of buffers which is 576 samples Consequently overrun/underrun will occur after 576 samples / 2.4 samples = 240 second Is the computation above correct if we consider there is no error on 48 KHz and no jitter is corrupting the system???

[ajgboomer]

Posted on February 14, 2013 at 22:54

Hi chinzei.tsuneo,

''In this point also, ST's audio example is wrong''. Can you share an example that is right? Regards, ajg

[ajgboomer]

Posted on February 14, 2013 at 23:01

Hi Tsuneo,

Some processing at the end of every DMA transfer completion is acceptable for a device like the STM32F4xx running with a 168mhz clock. It would be nice not have to do this, but there does not seem to be a way to manage it 'hands off'.

[tsuneo]

Posted on February 15, 2013 at 01:53

> Let's take the case of asynchronous mode and audio frequency is 48 KHz:

> if the TIM2 measures a desynchronization of 50 µs over 1 second For Asynchronous Sink, in shorter interval less than 1 sec, the feedback calculated with TIM2 is sent to host. The interval is declared at bRefresh field on the endpoint descriptor of the feedback (Synch) endpoint. Usually, it's 3 (8ms), 4 (16ms) or 5 (32 ms). The host changes the number of samples on packets, when it receives new feedback value. Tsuneo

[ajgboomer]

Posted on February 15, 2013 at 11:54

I had not considered having the Host modulate its rate of transmission. I need to review the usb Audio class capabilities. This document looks useful  www.usb.org/developers/devclass_docs/frmts10.pdf.

[lowpowermcu]

Posted on February 15, 2013 at 16:11

Hi ajg,

I think that the host must support the feedback and unfortunately windows XP doesn't support it (please correct me if I am wrong). You have to check if you want to use windows XP on your host.