[pulseaudio-discuss] long delay after "paplay -s somehost foo.wav"
gmane at colin.guthr.ie
Tue Aug 9 07:03:27 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
> 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
> 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
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
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss