[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Sun, September 22, 2013 1:55 am, Tanu Kaskinen wrote:
> 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.
>

That seems like a reasonable explanation. The device I am using is an
onboard hda_intel and I am seeing a lot of xruns in the jack console
messages.

>From the perspective of an ignorant user this appears to be a sort of bug
in that the audio stream is being delivered to the speakers but not to
jack_delay. Although ears can be deceiving I don't hear any obvious
dropouts.

Can you think of a way to mitigate this issue when using both jack and pa
at the same time?

I am seeing this issue with both 64 frames/period and 1024 . I usually run
with 1024 on JACK and that stable for me albeit I don't ever try to record
to jack apps with the onboard mic.

However, I use skype via PA regularly and it usually provides semi decent
quality for phone conversations (without jack running).

I tried using the skype call testing service with jack+pa. I can hear my
voice and there are no obvious artefacts.

The end goal here is to find a way to accurately measure the round trip
latency when both JACK and PA are in use and figure out a robust method to
achieve the lowest latency possible while PA is connected to JACK .
Ideally I would like to measure the latency between each node in the
graph.

Does the PA API allow for obtaining latency measurements between nodes in
the graph? Could I spin up a tool to gather that data for testing/QA
purposes? By combining that info with jack_delay and a couple of other
system metrics I might be able to gain some useful insight into tweaking
the system to provide better performance other than installing a realtime
kernel and setting the priorities with rtirq. That's assuming that there
is anything that can be done to either PA or JACK to make it perform
better.





--
Patrick Shirkey
Boost Hardware Ltd