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