[pulseaudio-discuss] long delay after "paplay -s somehost foo.wav"
pgf at foxharp.boston.ma.us
Tue Aug 9 08:03:55 PDT 2011
> '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?)
> Colin Guthrie
> 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
paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 72.5 degrees)
More information about the pulseaudio-discuss