a question of USB audio playing .

I am sure this question has nothing to do with the driver itself because it seems much related to HW. However , I really don’t know where I should get help … So ,I get here .

I are developing a USB wireless headset, consisting of headset and dongle . The dongle is interfaced with PC via USB port and enumerated as audio device .
For it , sampling rate is 48K and bit resolution is 16Bits .

Now , I have a question:

because of the slight deviation of extern crystal oscillator?saying ,48.001K or 47.999K), the codec might consume audio data faster or slower than what it is. As a result, it leads to frequent pauses of voice and enduser’s sadness.

I suppose it is an general question which lots of developers might have.
please help to enlighten me if you know anything …
Thanks a lot .

That should still work. You set up an isoch transfer, most of the frames use the entire reserved bandwidth, but once in a while, you get a frame that is shorter than max reserved.

Thanks to navab .

I ensure you misunderstand what I mean .

Dongle gets 48K samples per sec from PC while Codec in Headset consumes the data faster than 48K (saying 48.001K ). That’s saying , there is a scenario where no data is fed to the codec …

Daniel Xie wrote:

because of the slight deviation of extern crystal
oscillator?saying ,48.001K or 47.999K), the codec
might consume audio data faster or slower than
what it is. As a result, it leads to frequent pauses
of voice and enduser’s sadness.

Sounds like your driver needs a buffer so that it’s playing back, say, a fraction of a second behind what’s coming out of the headset.

> I suppose it is an general question which lots of developers might have.

Several solutions of such a problem (sync/async/adaptive devices) are described in the USB spec itself.

More so, IIRC USB Audio spec mandates some of these approaches.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> Sounds like your driver needs a buffer so that it’s playing back, say, a fraction of a second behind

If there is a constant frequency difference between the internal oscillator and the USB clock - then this will just make interruptions more rare but still existing, and will have the cost of time lag in audio playback.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Thanks to each of you .

With the suggestion of Maxim S , I have overcome it .

Here is the solution :

I dynamically adjust codec clock according to the amount of valid data in buffer.

That’s saying , what speed codec consumes audio data relies on the amount of data in buffer.

Hope it’s helpful to you .