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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
