[LAU] Testing JACK and PA latency

[Len Ovens]

On Thu, 19 Sep 2013, Patrick Shirkey wrote:

> On Thu, September 19, 2013 7:19 pm, Hartmut Noack wrote:
>> Am 19.09.2013 10:46, schrieb Patrick Shirkey:
>>> Moving this thread to LAU as it seems to be a more generic issue now:
>>>
>>> I am testing the round trip latency when using PA and JACK together. I
>>> have the following connection graph:
>>>
>>> jack_system (in) -> pa_source (in) -> audacity (in) -> audacity (out) ->
>>> pa sink (out) -> jack_system (out)
>>>
>>
>> Unless your research is completely academic I do not see a practical use
>> for its results on the user-side.
>
> This is entirely professionally motivated and will also have major
> benefits to academia too. I'm seeking suggestion on how to go about it not
> arguments for why or if this is a useful thing to do... ;-)
>
>> For Audacity latency is not a big
>> issue.
>
> You can replace audacity with *any* application that can provide (near) 0
> internal latency and full duplex pass through.

I expect the sample rate is to remain the same from one end to the other? 
With pulse (or at least some of the apps that work with pulse) that is not 
a given.

My first thought would be an analog solution, scope the sound going in and 
coming out. Send short pulses of sound through. Anything that is purely 
with in the computer would require two measurements, both starting and 
ending in jack. So the length of time from jack-alsa-cable-alsa-jack would 
be added to jack-pulse-app-pulse-jack. I don't know If you would be 
measuring jack twice when you shouldn't but that part of the journey is 
probably the best known.

just a thought, jack-alsa-cable-alsa-jack-pulse-app-pulse-jack might give 
valid results.

There are some things that could be removed to figure out just parts of 
the path. Jack-pulse-pulse-jack for example. I don't know if pulse deals 
differently time wise with it's internal routing than with a app though.

--
Len Ovens
www.ovenwerks.net