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

[Colin Guthrie]

'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.

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.

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/]