[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Sun, September 22, 2013 4:37 pm, Tanu Kaskinen wrote:
> On Sun, 2013-09-22 at 02:30 +1000, Patrick Shirkey wrote:
>> On Sun, September 22, 2013 1:55 am, Tanu Kaskinen wrote:
>> > 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.
>
> If you want to get the minimum latency of this path:
>
>     jack_delay -> pulseaudio -> application -> pulseaudio -> jack_delay
>
> then you should use an application that reports underruns and lets you
> control the latency that the application requests from pulseaudio. Then
> you can tune the application latency to find the point where you start
> to get underruns. You should also know the maximum internal buffer size
> of the application. You probably need to write that application
> yourself.
>

I am using ecasound which reports underruns and allows me to set the
internal buffer. I have it set to 64 frames/period for this test.

It does report occasional underruns but over a 6 hour period I had about
20. Based on that info it leads me to PA sink as the bottle neck. Do you
have any suggestions about how I can rule that out?

> pa_stream_get_latency() gives you an estimate of the latency between the
> hardware and your application. pa_stream_get_timing_info() gives some
> more details about how that latency is split between different parts in
> pulseaudio.
>

Can you or anyone else recommend an example app that I can use as a
reference for this code?

I am thinking of building an app that will let me gather latency data from
both PA and JACK. I would like it to measure the timing of a signal pulse
as it is transferred between each node in the graph. It would communicate
with both JACK and PA at the same time. Do you see any insurmountable
blockers to achieving that goal from a technical perspective in regards to
PA?



--
Patrick Shirkey
Boost Hardware Ltd