[pulseaudio-discuss] Confusing pa_stream_drain behaviour

Matthew Gregan kinetik at flim.org
Wed Nov 10 15:17:23 PST 2010


I've been debugging a situation where snd_pcm_drain takes an unusually long
time when using the alsa-pulse plugin.  I reduced the testcase to a one
using the PA client API directly as the culprit seems to be the operation
returned by pa_stream_drain takes an unusually long time to complete.  I've
attached the testcase if anyone's interested.

I'm running Fedora 13 with all updates applied.  PulseAudio version:
pulseaudio-0.9.21-6.fc13.x86_64.  Sound hardware is Intel Corporation 5
Series/3400 Series Chipset High Definition Audio (rev 06).  I haven't tested
against git HEAD because my PA clients fail to connect to the PA server I

The testcase writes N seconds (as specified on the command line) of 48kHz
mono audio, then immediately calls pa_stream_drain and waits on the
resulting operation by testing the operation's status in a loop.

My expectation is that the drain complete when the audio finishes playing,
so it should take roughly N seconds to complete having written N seconds of
audio.  What I'm seeing is an additional 2 second delay:

% time ./a.out 1
write 48000 samples
./a.out 1  0.00s user 0.01s system 0% cpu 3.054 total
% time ./a.out 2
write 96000 samples
./a.out 2  0.00s user 0.01s system 0% cpu 4.057 total
% time ./a.out 10
write 480000 samples
./a.out 10  0.01s user 0.00s system 0% cpu 12.109 total

Matthew Gregan                     |/
                                  /|                    kinetik at flim.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ptest_drain2.c
Type: text/x-csrc
Size: 3797 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20101111/6936db20/attachment.c>

More information about the pulseaudio-discuss mailing list