[pulseaudio-discuss] long delay after "paplay -s somehost foo.wav"

Paul Fox pgf at foxharp.boston.ma.us
Tue Aug 9 08:03:55 PDT 2011

colin wrote:
 > 'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble:
 > > i have a long-standing problem with commandline access to pulseaudio
 > > across the network.
 > > 
 > > i have a scripted application that needs to be able to play multiple
 > > sound files back to back, with as little silence between them as
 > > possible.  (the soundbites are spoken phrases, so a tiny gap is
 > > acceptable.)
 > > 
 > > but this:
 > >     paplay -s server one.wav
 > >     paplay -s server two.wav
 > > will result in a delay of over 2 seconds between "one" and "two". 
 > > examining the operation of paplay and the remote pulseaudio server
 > > with strace tells me that the delay is occuring at the end of the
 > > first command (as opposed to the beginning of the second).
 > > 
 > > the delay is a 2.2 second wait at the end of paplay for some sort of
 > > final acknowledgement from the server.  on the server side, it seems
 > > that this delay is spent waiting from data from the audio driver? 
 > > (just guessing about this, since i'm just looking at strace, and the
 > > fd being polled isn't a file node, but appears in /proc/<pid>/fd as
 > > "anon_inode:[eventfd]".)
 > > 
 > > in any case, since this may be a well-known problem (or feature, even
 > > :-), i figure i should ask about it before going further.  i should add
 > > that on another incarnation of this application setup, i've used nasd
 > > and auplay to transfer the audio, and the files play almost seamlessly.
 > > 
 > > my setup:
 > > i'm running 0.9.21-63-gd3efa-dirty on ubuntu 10.10 on both clients and
 > > server.  the protocol is enabled with:
 > >     load-module module-native-protocol-tcp  auth-anonymous=1
 > > and the server is running in system mode (because the audio needs to
 > > work when no one is logged in).
 > > 
 > > thanks in advance for any suggestions.
 > This is likely related to the drain. In order to be 100% sure that the
 > data is no longer needed (as it may be needed by rewind buffers) we have
 > to wait.

thanks.  is there a way to tell the connection that waiting for the
drain is unnecessary?  obviously pa_play won't do this, but i'm
willing to enhance/modify my own version of that, or some other tool,
if it's feasible.

 > There are a few bug reports about this kind of thing in e.g. the simple
 > protocol, but I'm not sure we can solve it 100% in all cases.
 > The 2s delay is likely related to the amount of audio that is buffered
 > by default.

likewise, how would i control how much buffering is in use?

i understand one or both of these might be FAQ-like questions -- if
so, just a pointer to the right level or section of an API would be

(i suppose it would be useful to verify that the wait for the drain
is really the culprit -- would that be logged, if i were looking in
the right place, with the right stuff enabled?)


 > Col
 > -- 
 > Colin Guthrie
 > gmane(at)colin.guthr.ie
 > http://colin.guthr.ie/
 > Day Job:
 >   Tribalogic Limited [http://www.tribalogic.net/]
 > Open Source:
 >   Mageia Contributor [http://www.mageia.org/]
 >   PulseAudio Hacker [http://www.pulseaudio.org/]
 >   Trac Hacker [http://trac.edgewall.org/]
 > _______________________________________________
 > pulseaudio-discuss mailing list
 > pulseaudio-discuss at lists.freedesktop.org
 > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 72.5 degrees)

More information about the pulseaudio-discuss mailing list