[LAU] Testing JACK and PA latency
pshirkey at boosthardware.com
Thu Sep 19 14:04:02 UTC 2013
On Thu, September 19, 2013 11:48 pm, Len Ovens wrote:
> 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
>>> 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
>> 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)
>> 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.
I'm wondering if this might work:
1: initiate signal pulse (500hz) in jack_delay (out) -> pa source (in) ->
custom app (in)
2: trigger *new* response signal at different frequency (400 hz) from
custom app (out) -> pa sink (out) -> jack_system (out) -> jack_system (in)
-> jack_delay (in)
The frequency of the signal could be modified at various points in the
graph to provide more timing information?
Could the custom app communicate with jack_delay or maybe they could pass
a time stamp in the signal or write it to a log?
It starting to sound a lot like mtc now. Surely we are not the first to
have encountered this issue?
Boost Hardware Ltd
More information about the Linux-audio-user