On Thu, 2013-09-19 at 23:54 +1000, Patrick Shirkey wrote: > On Thu, September 19, 2013 6:52 pm, Patrick Shirkey wrote: > > > > On Thu, September 19, 2013 6:42 pm, Tanu Kaskinen wrote: > >> On Wed, 2013-09-18 at 04:28 +1000, Patrick Shirkey wrote: > >>> Hi, > >>> Can someone shed some light on the best case and typical latency that > Pulse provides for standard operations? > >> What do you mean by standard operations? I'd estimate volume changes > etc. normally (on an ALSA sink) have a few millisecond latency (best > case 0.5 ms audio buffer + scheduling latency). > > > > Just a "normal" round trip signal flow, for example : PA (in) -> > audacity > > (in) -> audacity (out) -> pa (out) > > > > > >>> Also how that is affected by using jack-sink assuming jack is set to the > >>> lowest possible latency that a device can handle? > >> When jackd asks for N frames from PulseAudio, pulseaudio will render N > frames. There's no extra buffering done in the Jack sink, so volume > changes etc. will have latency that is roughly the same as the normal > Jack client latency. > > > > Do you have an suggestions on how to get an accurate measurement? > > > > > I'm using this method: > > jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay > > jack is set to 64/48000/2 > > Using audacity with 0 internal latency and in pass through mode I see the > following results. It starts out as 10.667ms and after a few seconds it > climbs up to 70.667 ms. > > I see similar results with ecasound instead of audacity using the > following chain: > > jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay > > ecasound -f:32,2,48000 -b:64 -i alsa -o alsa > > In that case it starts at 60.000 ms and climbs upto 572.000 ms after a few > seconds of running the test. > > Full console logs here: > > http://boosthardware.com/pa-jack-latency.txt > > This appears to be caused by PA adding more buffer on a regular basis. Any > thoughts on why this is happening and how to stop it? PulseAudio doesn't increase the buffering on the fly (well, some small adjustments are done with ALSA, but you're using JACK, so that's irrelevant). If the source produces audio faster than the sink consumes it, then I guess the buffer might accumulate in the PulseAudio client (audacity/ecasound). I think one reason for the source "running faster" could be that the sink side is experiencing underruns, which causes silence to be sent to jack_delay every now and then, and this silence is not compensated by dropping a matching amount of data from the PA client. -- Tanu
