colin wrote: > '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. thanks. is there a way to tell the connection that waiting for the drain is unnecessary? obviously pa_play won't do this, but i'm willing to enhance/modify my own version of that, or some other tool, if it's feasible. > > 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. likewise, how would i control how much buffering is in use? i understand one or both of these might be FAQ-like questions -- if so, just a pointer to the right level or section of an API would be helpful. (i suppose it would be useful to verify that the wait for the drain is really the culprit -- would that be logged, if i were looking in the right place, with the right stuff enabled?) paul > > 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/] > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss =--------------------- paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 72.5 degrees)
