[LAU] Testing JACK and PA latency
len at ovenwerks.net
Thu Sep 19 13:48:54 UTC 2013
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
> 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
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
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.
More information about the Linux-audio-user