[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Tue, September 24, 2013 10:33 pm, Patrick Shirkey wrote:
>
> 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?
>

I had verification from the ecasound developer Kai Vehmanen that ecasound
does not have an internal buffer that could be affecting the latency in
this way. It just buffers 64 frames and if it can't keep up it will drop
data and report an underun. In my tests there were just a few underruns
over several hours so it appears safe to rule out ecasound.

Does anyone have any suggestions for testing the PA Stream Buffer to check
if it is a bottleneck in my test environment?




--
Patrick Shirkey
Boost Hardware Ltd