[pulseaudio-discuss] Need help to reduce delay with USB, mic using pulseaudio

[Alexander E. Patrakov]

12.08.2011 15:50, Arun Raghavan wrote:
> On Fri, 2011-08-12 at 14:58 +0530, ashwanik wrote:
>> Hi Arun,
>>
>> Yes, When I use tsched=0 in default.pa, getting low delay but the audio
>> quality is not good as compared to the previous audio(audio with delay).
>> I am getting audio with noise(I think extra noise sample added with
>> audio). I have tried with kernel Version: 2.6.35&  2.6.38, in both case
>> results are same.
>>
>> I tested same usb mic on laptop and its working fine without any delay
>> problem, also tried USB mic with usb headset(playback sink) on
>> pandaboard but delay still persists.
>>
>>
>> Please help to figure out where is the problem.
>
> So the problem does appear to be related to timing. You're going to need
> to look more closely at the drivers. Since the problem is happening on
> USB as well, I'm wondering if there isn't something broken with your
> system timers, but that's just a guess.

I did some debugging for Abdul and Ashwanik. Results:

1) Their initial testing was on 2.6.35 kernel. That kernel could not 
even sustain the "arecord -f cd -c 1 -D hw:USBMICROPHONE 
--period-size=512 --buffer-size=2048 /dev/null" test due to constant 
xruns, so it was pointless to debug pulseaudio.

2) 2.6.38 (the default ubuntu kernel) passes the above test and works 
with "arecord | aplay" without pulseaudio. However, the "huge latency 
with pulseaudio" problem stays and is specific to USB audio. This is 
reproducible with their microphone + speaker device, and as well with a 
webcam (tested using module-loopback).

3) In the latency reported by module-loopback.c, the second number (i.e. 
the internal jitter buffer) dominates, both in USB => same USB and USB 
=> onboard audio cases: 63.91+733.32+11.65 ms

So, for me, it looks like the USB master clock (from which the USB audio 
clock is derived) is too unstable WRT the system timer as a reference, 
but this doesn't apply to the "internal audio vs system timer" situation.

> For what it's worth, Wim Taymans wrote a test module to quantify clock
> drift and jitter (but this does use the system clock as a reference).
> I've got a recently rebased branch at:
>
> http://cgit.collabora.com/git/user/arun/pulseaudio.git/log/?h=wtay/module-test
>
> This won't help you find (constant-value) bad driver timing reporting,
> but will at least be one data point in measuring how bad your timing
> information is.

Abdul, Ashwanik: the suggestion above is still valid. To test all your 
devices, though, you will have to use pavucontrol or a similar tool in 
order to temporarily set the default sink and source first to your 
onboard audio device and then to the USB device, as that test module 
only tests the default sink and source.

-- 
Alexander E. Patrakov