[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Mon, September 23, 2013 6:11 pm, Tanu Kaskinen wrote:
> On Sun, 2013-09-22 at 20:03 +1000, Patrick Shirkey wrote:
>> On Sun, September 22, 2013 4:37 pm, Tanu Kaskinen wrote:
>> > 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?
>
> The audio is accumulating in some buffer, and the JACK sink in
> PulseAudio doesn't have any buffer, so it's not the sink. It could be
> some other buffer in PulseAudio, or it could be a buffer in ecasound.
>
> Saying that ecasound is configured with 64 frames/period isn't terribly
> informative, because I don't know how ecasound handles the transfer from
> the input to the output. Does it push the data immediately to the output
> when it gets something from the input, or are both directions callback
> based? If the former, then the data can accumulate in the stream buffer
> in PA, and if the latter, then there has to be an intermediate buffer
> between the input and the output in ecasound, and the data can
> accumulate there.
>

I've asked for some more details on the ecasound list.

If the PA stream buffer is kicking in, Is there any way I can verify if it
is happening? is there anything I can do to minimise that affect?



>> > 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?
>
> No. And anyway, if you want to really measure the latency (detect when a
> signal pulse arrives at a measurement point), these functions are
> useless (except for checking that is PulseAudio reporting the latency
> correctly or not, which would actually be quite interesting
> information).
>

Usually the more information available the better, right?


>> 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?
>
> So you would generate a pulse in a jack client, and detect it in a PA
> client, and then detect it again in a jack client? No, I don't see any
> obstacles to doing that.
>

I'm looking into it.




--
Patrick Shirkey
Boost Hardware Ltd