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.
paul
=---------------------
paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 69.6 degrees)
