Re: [LAU] Testing JACK and PA latency

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
>>> 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.
>

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?

--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user