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)
