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

[Paul Fox]

lu wrote:
 > Hi,
 > 
 > On Wed, Aug 10, 2011 at 09:47:47PM +0800, Paul Fox wrote:
 > > 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.
 > 
 > I did some experiment to set the tsched buffer size down a little bit
 > and for me the wait time becomes smaller. This makes sense since the
 > total buffer becomes smaller and the time to wait it to be drained is
 > smaller.
 > 
 > As this parameter is not exported via module-udev-detect, so you have to
 > use this hack method instead:

thanks!   will doing this result in different behavior than modifying
the pa_buffer_attr struct that's passed to pa_simple_new()?  (other than
it affecting all clients, instead of just one, that is.)

paul

 > 
 > pacmd
 > >> list-modules
 > [find the module index of your alsa card]
 > >> unload-module <the-above-index-you-find>
 > >> load-module module-alsa-card device_id="0" name="pci-0000_00_1b.0"
 > card_name="alsa_card.pci-0000_00_1b.0" namereg_fail=false tsched=yes
 > ignore_dB=no sync_volume=yes
 > card_properties="module-udev-detect.discovered=1"
 > tsched_buffer_size=<some-number>
 > 
 > [note the parameter here may differ from yours, but you can get it from
 > list-modules above, see the arguments part]
 > 
 > Change the tsched_buffer_size to some number smaller. How to decide the
 > number? Before you unload this module, invoke list-sinks and check this
 > property: device.buffering.buffer_size. You may need to try half the
 > number again and again to see how it fixes your problem.
 > 
 > The cons of this action is you gets poor power consumption, the wakeup
 > gets more and if it's too small, more chances of underrun. Be cautious.
 > It's more like a tuning thing. You can take a try.
 > 
 > > 
 > > 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)
 > > _______________________________________________
 > > pulseaudio-discuss mailing list
 > > pulseaudio-discuss at lists.freedesktop.org
 > > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
 > 
 > -- 
 > guanqun

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