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? -- Patrick Shirkey Boost Hardware Ltd
