cancel
Showing results for 
Search instead for 
Did you mean: 

Can the crystal-less USB clock recovery system (CRS) support perfect USB Audio Iscochronous sample rate?

caleb
Associate III
Posted on June 17, 2014 at 19:20

Hi there,

   I'd like to build a USB Audio Class device that can synchronize to the 1kHz SOF so that samples are never lost or added due to clock frequency differences between the host crystal and the sample rate oscillator.

In order to implement this, the clock recovery has to synchronize continuously, with the SOF so that exactly 1ms of audio data happens in one SOF period.  

I currently have a clock setup so that HCI48 is synchronized to the USB SOF, and the MCO is set to the HCI48 as 12 MHz.  The MCO then drives a PLL (in a codec) that does an exact frequency conversion of 12MHz -> 12.288MHz.  However, the problem is that apparently the CRS is close enough to 48 that no USB problems occur, the CRS is not pegged perfectly on to the USB SOF frequency, so drift between SOF and the sample clock still happens.

I guess we need software that tracks buffer levels and modifies the CRS via software to constantly tweak the CRS for perfect tracking, right?  

Has anybody been through this or know if it's possible?

Thanks,

  -Caleb

#crystal-less-usb-audio-clock-crs
7 REPLIES 7
zzdz2
Associate II
Posted on June 17, 2014 at 19:59

It only makes sense if you don't care about audio quality.

caleb
Associate III
Posted on June 17, 2014 at 20:32

Ah, after a little more digging, it looks possible, but not good solution for our (or probably anybody's) application.  The steps available in the 48MHz CRS are about 67kHz.  That amounts to about 0.14% error (1400 PPM).  That would require tweaking the clock frequency about 22 times a second to keep +-1 sample latency (at 16kHz sample rate).  This would be for voice, so fidelity requirements are slightly relaxed (i.e. pristine jitter-free clocks are not absolutely necessary), but adjusting that often definitely does not sound like a good idea.  

This works fine with a CS2100-CP, which has a resolution as low as 1 PPM, as opposed to the ST CRS 1400 PPM.    So... bottom line is... it's not gonna work for us.   The CS2100-CP has the added benefit that it is specifically designed to keep low jitter at the output even in the presence of high jitter in the SOF packet arrival time.

Oh well.  I guess we either need to stick with asynchronous mode or use a CS2100-CP.  (~$3).  

-Caleb

lowpowermcu
Associate II
Posted on June 18, 2014 at 10:50

Hi Crome,

You need a single step and not 22 steps.

For me it is possible to do that.

Cheers

zzdz2
Associate II
Posted on June 18, 2014 at 11:16

Oh well.  I guess we either need to stick with asynchronous mode or use a CS2100-CP. 

Asynchronous mode is not bad, simpler and more robust than SOF-synced clock recovery.

jjackbauer7
Associate III
Posted on June 18, 2014 at 12:40

Hi Crome,

That looks an interesting low cost usb audio device !

caleb
Associate III
Posted on June 18, 2014 at 17:54

knik wrote:

Asynchronous mode is not bad, simpler and more robust than SOF-synced clock recovery.

Ah, could you tell me a little more? Our application requires full-duplex, and bit-perfect data transport.  I always worried that with asynchronous operation the host OS might add or drop samples, which would be catastrophic to our application.    Can even Windows manage bit-perfect transmission over USB these days?  I know it's been terrible in the past, but perhaps it's okay these days. 

Thanks,

 -Caleb

zzdz2
Associate II
Posted on June 19, 2014 at 10:21

Ah, yes, there might be some Windows driver problem.

I tested it only in Linux, asynchronous bit-perfect full-duplex 48kHz soundcard, no glitches at all.

Anyway, explicit feedback seems tricky at first but when you understand the idea it's quite simple.

USB standard defines dome sophisticated ways to calculate the feedback but I used much simplified approach and it works well.

Normally I request 48 samples per frame, when number of samples in buffer is less than optimal 49 samples are requested, when more than optimal then 47 samples.

No problem, it does work but who knows how widows handles such thing.