[Blink] Trouble with USB headsets

[John Nielsen]

We have a bunch of Mac Mini's with Snow Leopard, Blink Pro and USB headsets. We get regular reports of static, echoes and/or distortion or "robot voice" from callers, very much like described in this thread:

https://discussions.apple.com/thread/2166616?start=45&tstart=0

The gist of the thread is that the problem is widespread and due to a change Apple made to its USB audio driver in 10.5.7 and later versions of Mac OS. I am of the opinion that this is an Apple problem and we are looking at different (types of) headsets as a short term workaround and bugging Apple as a possible long-term workaround.

However, on the page I linked to there is some indication that application developers could also fix or work around the issue:

On Mac OS X 10.5.6 & prior, the USB audio driver publishes 2 audio engines, one for input stream and another for output stream. Applications could change sample rate on one audio stream without affecting the other stream. On 10.5.7 & onwards, a change in the USB audio driver publishes only 1 audio engine for both input & output streams. Changing sample rate on one stream will affect another stream (technically, the sample rate resides on the audio engine, so changing the sample rate naturally affects both streams). So in this case, changing the sample rate causes the input stream to run at a different rate that originally when Ventrilo launched. Ventrilo doesn't handle the sample rate change properly, resulting in the audio corruption (robotic/garbled, etc).

(a) This problem actually could occur on Mac OS X 10.5.6, depending on the USB audio device used. If the device can only support one sample rate, then this problem will also occur after the USB audio driver switches the sample rate on both streams when it detected one stream is falling behind.
(b) This problem is not specific to USB audio driver. Using Ventrilo for example with Firewire audio device also exhibits similar issue. The Firewire audio driver also puts input & output audio stream on the same audio engine.

In conclusion, this is a 3rd party application developer issue. Ventrilo (& other programs such as Mumble) need to listen to and handle sample rate change properly.

So I wanted to ask: does Blink Pro ever try to change the sample rate on either the input or output audio streams? If so, do you think this is something that could be addressed within the application? The headsets we use (and most I have encountered) only support 16bit at 44.1 or 48kHz.

Thanks,

JN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20120302/f7bb9704/attachment.html>