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

[Paul Fox]

colin wrote:
 > 'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble:
 ...
 > > 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". 
 ...
 > 
 > 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.

thanks.  i found this: http://www.pulseaudio.org/ticket/866

it certainly sounds like a fix will be a long time coming.  it feels
to me that there should be a way for a stream to be started with a
different "contract", i.e., "i will never rewind this stream.  please
deliver the data on a best-effort basis.  i don't require
acknowledgement of the last byte." i.e., exactly the conditions needed
by most real-world uses of pa_play.

 > The 2s delay is likely related to the amount of audio that is buffered
 > by default.

i've modified the pacat-simple.c example to let me play with the
pa_buffer_attr passed to pa_simple_new, but can't seem to find a
combination that avoids the 2s wait.

removing the call to pa_simple_drain(), however, and (hack alert!)
substituting usleep(100000) seems to do the trick, for me.  i do get
a click between played files, though, so i'm not done.

paul

 > 
 > Col
 > 
 > -- 
 > 
 > Colin Guthrie
 > gmane(at)colin.guthr.ie
 > http://colin.guthr.ie/

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