jack (1 and 2) latency reporting

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

jack (1 and 2) latency reporting

Robin Gareus
Hi Jack-devs,

While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
Luis (see thread " Differences in latency between USB and internal audio
interfaces") I stumbled upon a small inconsistency in latency reporting
of both jack1 and jack2mp:

during start-up JACK reports (with '-n3'):

  ALSA: use 3 periods for capture
  ALSA: use 3 periods for playback

However querying the physical port latency with
jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
'-n3 -p1024':

 system:capture_1
      port latency = 1024 frames
 system:playback_1
      port latency = 2048 frames

AFAIU it the startup-message should read:
_1_ period of latency for capture, _2_ for playback.

I did not look into the code and I might be wrong, but I guess you
cracks will know.. it seems to be a rather small bug in the
startup-message (for the ALSA backend).

The quaint part is that it is present in both JACK1 and JACK2, so maybe
I'm just interpreting these values wrong ?!

Cheers!
robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
On Thu, Dec 09, 2010 at 09:25:38PM +0100, Robin Gareus wrote:

> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
> Luis (see thread " Differences in latency between USB and internal audio
> interfaces") I stumbled upon a small inconsistency in latency reporting
> of both jack1 and jack2mp:
>
> during start-up JACK reports (with '-n3'):
>
>   ALSA: use 3 periods for capture
>   ALSA: use 3 periods for playback
>
> However querying the physical port latency with
> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
> '-n3 -p1024':
>
>  system:capture_1
>       port latency = 1024 frames
>  system:playback_1
>       port latency = 2048 frames
>
> AFAIU it the startup-message should read:
> _1_ period of latency for capture, _2_ for playback.
>
> I did not look into the code and I might be wrong, but I guess you
> cracks will know.. it seems to be a rather small bug in the
> startup-message (for the ALSA backend).
>
> The quaint part is that it is present in both JACK1 and JACK2, so maybe
> I'm just interpreting these values wrong ?!

After reading this 10 times I still fail to see the problem
or inconsistency...

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Robin Gareus
On 12/09/2010 09:44 PM, [hidden email] wrote:

> On Thu, Dec 09, 2010 at 09:25:38PM +0100, Robin Gareus wrote:
>
>> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
>> Luis (see thread " Differences in latency between USB and internal audio
>> interfaces") I stumbled upon a small inconsistency in latency reporting
>> of both jack1 and jack2mp:
>>
>> during start-up JACK reports (with '-n3'):
>>
>>   ALSA: use 3 periods for capture
>>   ALSA: use 3 periods for playback
>>
>> However querying the physical port latency with
>> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
>> '-n3 -p1024':
>>
>>  system:capture_1
>>       port latency = 1024 frames
>>  system:playback_1
>>       port latency = 2048 frames
>>
>> AFAIU it the startup-message should read:
>> _1_ period of latency for capture, _2_ for playback.
>>
>> I did not look into the code and I might be wrong, but I guess you
>> cracks will know.. it seems to be a rather small bug in the
>> startup-message (for the ALSA backend).
>>
>> The quaint part is that it is present in both JACK1 and JACK2, so maybe
>> I'm just interpreting these values wrong ?!
>
> After reading this 10 times I still fail to see the problem
> or inconsistency...

 ALSA: use 3 periods for capture
 ALSA: use 3 periods for playback

= 6 periods of total latency

!= ( 1024 + 2048 ) / 1024 = 3 periods total latency

HTH,
robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
On Thu, Dec 09, 2010 at 09:48:00PM +0100, Robin Gareus wrote:

>  ALSA: use 3 periods for capture
>  ALSA: use 3 periods for playback
>
> = 6 periods of total latency

No, 3.
 
> != ( 1024 + 2048 ) / 1024 = 3 periods total latency

-n 3 means that the sample buffers for both capture and
playback are 3 periods long. Asssume for a moment these
are the actual HW buffers, as coild well be the case for
e.g. a PCI card.

Let the period size be N.

At the end of each period the soundcard will generate
an interrupt to the driver. The application (e.g. jack)
wakes up and assuming it uses ALSA's mmap interface it
gets two pointers into the HW buffers:

* The capture pointer points to first of the N input samples
  that have  been input during the period preceding the last
  interrupt. The app is supposed to use these as input. In
  the meantime, the HW will write to the next period in the
  capture buffer.

  For -n 2, the app must read this data before the next
  interrupt, as otherwise they will be overwritten by
  the HW.
  For -n 3, the app has one more period to read the data.
  For -n 4, the app has two extra periods, etc.

* The playback pointer points to the first of the N output
  samples that have been output during the period preceding
  last interrupt. The app is supposed to overwrite these
  with new data. In the meantime, the HW will output the
  next period in the playback buffer.

  For -n 2, this must be done before the next interrupt,
  as otherwise the HW will re-use old data for output.
  For -n 3, the app has one more period to supply the
  new data.
  For -n 4, the app has two extra periods, etc.

Now imagine an app that just copies the data at the capture
pointer to the playback pointer. Make some drawings to help
you imagine what happens. The conclusion will be that any
input signal will re-appear at the output after K periods
where K is the number of periods in the buffers.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Stéphane Letz
In reply to this post by Robin Gareus

Le 9 déc. 2010 à 21:48, Robin Gareus a écrit :

> On 12/09/2010 09:44 PM, [hidden email] wrote:
>> On Thu, Dec 09, 2010 at 09:25:38PM +0100, Robin Gareus wrote:
>>
>>> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
>>> Luis (see thread " Differences in latency between USB and internal audio
>>> interfaces") I stumbled upon a small inconsistency in latency reporting
>>> of both jack1 and jack2mp:
>>>
>>> during start-up JACK reports (with '-n3'):
>>>
>>>  ALSA: use 3 periods for capture
>>>  ALSA: use 3 periods for playback
>>>
>>> However querying the physical port latency with
>>> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
>>> '-n3 -p1024':
>>>
>>> system:capture_1
>>>      port latency = 1024 frames
>>> system:playback_1
>>>      port latency = 2048 frames
>>>
>>> AFAIU it the startup-message should read:
>>> _1_ period of latency for capture, _2_ for playback.
>>>
>>> I did not look into the code and I might be wrong, but I guess you
>>> cracks will know.. it seems to be a rather small bug in the
>>> startup-message (for the ALSA backend).
>>>
>>> The quaint part is that it is present in both JACK1 and JACK2, so maybe
>>> I'm just interpreting these values wrong ?!
>>
>> After reading this 10 times I still fail to see the problem
>> or inconsistency...
>
> ALSA: use 3 periods for capture
> ALSA: use 3 periods for playback
>
> = 6 periods of total latency
>
> != ( 1024 + 2048 ) / 1024 = 3 periods total latency
>
> HTH,
> robin

Jack2 has an extra buffer latency in asynchronous mode. Could it be that?

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Paul Davis
In reply to this post by Robin Gareus
On Thu, Dec 9, 2010 at 3:25 PM, Robin Gareus <[hidden email]> wrote:

> Hi Jack-devs,
>
> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
> Luis (see thread " Differences in latency between USB and internal audio
> interfaces") I stumbled upon a small inconsistency in latency reporting
> of both jack1 and jack2mp:
>
> during start-up JACK reports (with '-n3'):
>
>  ALSA: use 3 periods for capture
>  ALSA: use 3 periods for playback

this is how the card is configured. it is correct.

>
> However querying the physical port latency with
> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
> '-n3 -p1024':
>
>  system:capture_1
>      port latency = 1024 frames
>  system:playback_1
>      port latency = 2048 frames

these two values are incorrect for n=3

the entire latency reporting system is still in need of the overhaul i
described months ago. however, this doesn't affect this particular
issue, which is that the port latencies shown here should be
(nperiods-1)*period_size and (nperiods*period_size) respectively.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Robin Gareus

On Dec 9, 2010, at 11:33 PM, Paul Davis wrote:

> On Thu, Dec 9, 2010 at 3:25 PM, Robin Gareus <[hidden email]> wrote:
>> Hi Jack-devs,
>>
>> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
>> Luis (see thread " Differences in latency between USB and internal audio
>> interfaces") I stumbled upon a small inconsistency in latency reporting
>> of both jack1 and jack2mp:
>>
>> during start-up JACK reports (with '-n3'):
>>
>>  ALSA: use 3 periods for capture
>>  ALSA: use 3 periods for playback
>
> this is how the card is configured. it is correct.

It actually does not sound like it is.

The _measured_ latency in this case '-n3 -p1024' with a HDA soundcard is

4126ms = 1024 + 3* 1024 + K

with K being some small positive constant (here 30 frames).
It is much less than the 2*3*1024 frames latency reported at JACK startup.

A complete table with measurements of six soundcards can be found here:
http://wiki.linuxaudio.org/wiki/jack_latency_results

The "RIL" and "ROL" columns are the values reported by 'jack_lsp -l'.
These values (reported by jack_port_get_latency() for physical ports) are correct (apart from "K" and for USB devices which have 1 period additional latency but at most 1024 frames).

The startup message of jackd (using the ALSA backend) is always consistent - it displays the value entered for "-n"  for both ports.

>>
>> However querying the physical port latency with
>> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
>> '-n3 -p1024':
>>
>>  system:capture_1
>>      port latency = 1024 frames
>>  system:playback_1
>>      port latency = 2048 frames
>
> these two values are incorrect for n=3
>
> the entire latency reporting system is still in need of the overhaul i
> described months ago. however, this doesn't affect this particular
> issue, which is that the port latencies shown here should be
> (nperiods-1)*period_size and (nperiods*period_size) respectively.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
In reply to this post by Paul Davis
On Thu, Dec 09, 2010 at 05:33:46PM -0500, Paul Davis wrote:

> these two values are incorrect for n=3

They are correct.
 
> the entire latency reporting system is still in need of the overhaul i
> described months ago. however, this doesn't affect this particular
> issue, which is that the port latencies shown here should be
> (nperiods-1)*period_size and (nperiods*period_size) respectively.

Now *that* would be completely wrong.

Ignoring conversion delay and any implementation overhead,
let T be the period time, and t_k the start of cycle k :

The first sample of cycle k was at the physical input at

  t_k - T   (i.e. one period before the start of the cycle)
 
if copied to the output buffer, it will appear at the physical
output at

  t_k + (N - 1) * T   (i.e. N - 1 periods after the start of
  the cycle).

Total roundtrip latency is the sum of the two, N * T,

not (2 * N - 1) * T as suggested by your proposal.

After years or providing wrong information, Jack's basic
latency latency reporting (for HW ports) is now correct.
Please leave it like it is.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Robin Gareus
In reply to this post by Stéphane Letz

On Dec 9, 2010, at 11:10 PM, Stéphane Letz wrote:

>
> Le 9 déc. 2010 à 21:48, Robin Gareus a écrit :
>
>> On 12/09/2010 09:44 PM, [hidden email] wrote:
>>> On Thu, Dec 09, 2010 at 09:25:38PM +0100, Robin Gareus wrote:
>>>
>>>> While doing the http://wiki.linuxaudio.org/wiki/jack_latency_tests with
>>>> Luis (see thread " Differences in latency between USB and internal audio
>>>> interfaces") I stumbled upon a small inconsistency in latency reporting
>>>> of both jack1 and jack2mp:
>>>>
>>>> during start-up JACK reports (with '-n3'):
>>>>
>>>> ALSA: use 3 periods for capture
>>>> ALSA: use 3 periods for playback
>>>>
>>>> However querying the physical port latency with
>>>> jack_port_get_latency() (or `jack_lsp -l`) JACK says e.g. for
>>>> '-n3 -p1024':
>>>>
>>>> system:capture_1
>>>>     port latency = 1024 frames
>>>> system:playback_1
>>>>     port latency = 2048 frames
>>>>
>>>> AFAIU it the startup-message should read:
>>>> _1_ period of latency for capture, _2_ for playback.
>>>>
>>>> I did not look into the code and I might be wrong, but I guess you
>>>> cracks will know.. it seems to be a rather small bug in the
>>>> startup-message (for the ALSA backend).
>>>>
>>>> The quaint part is that it is present in both JACK1 and JACK2, so maybe
>>>> I'm just interpreting these values wrong ?!
>>>
>>> After reading this 10 times I still fail to see the problem
>>> or inconsistency...
>>
>> ALSA: use 3 periods for capture
>> ALSA: use 3 periods for playback
>>
>> = 6 periods of total latency
>>
>> != ( 1024 + 2048 ) / 1024 = 3 periods total latency
>>
>> HTH,
>> robin
>
> Jack2 has an extra buffer latency in asynchronous mode. Could it be that?
>
> Stéphane
>


alas, no. the startup notice always shows the number given with -n ; no matter if --sync is used or not.

The latency reported by JACK for the physical ports (jack_lsp -l) however is correct  (for PCI devices at least) - both with --sync and without: see the RIL and ROL columns in Table 1 at http://wiki.linuxaudio.org/wiki/jack_latency_results

Anyway it's not a big issue. I just wondered if I'm interpreting the values wrong (since both jack 1 and 2 say the same thing) or if it is an inconsistency in logging in both implementations.
 
ciao,
robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
On Fri, Dec 10, 2010 at 12:14:08AM +0100, Robin Gareus wrote:

> alas, no. the startup notice always shows the number given with -n ; no matter if --sync is used or no

Of course it does. It just reports the buffer size used by ALSA
which depends only on the -n paramater and not on if sync mode
is used or not.

Sync mode is what jack1 does. The other one adds one period of
latency. Compare

(A)

1. read capture data,
2. perform processing cycle,
3. write playback data generated by (2).

to

(B)

1. write playback data generated in previous cycle,
2. read capture data,
3. perform processing cycle and store results.

A is sync mode, also jack1 mode.
B is jack2's default mode.

The actual latency values as reported by jack2 should be different
for the standard and sync modes. If they are not that is a bug.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Paul Davis
In reply to this post by Fons Adriaensen-2
On Thu, Dec 9, 2010 at 5:59 PM,  <[hidden email]> wrote:

> On Thu, Dec 09, 2010 at 05:33:46PM -0500, Paul Davis wrote:
>
>> these two values are incorrect for n=3
>
> They are correct.
>
>> the entire latency reporting system is still in need of the overhaul i
>> described months ago. however, this doesn't affect this particular
>> issue, which is that the port latencies shown here should be
>> (nperiods-1)*period_size and (nperiods*period_size) respectively.
>
> Now *that* would be completely wrong.
>
> Ignoring conversion delay and any implementation overhead,
> let T be the period time, and t_k the start of cycle k :

    [ ... math ... ]

the numbers displayed are not what you are computing above.
there is no display of roundtrip latency. there is only:

 input latency - worst case delay between a sample
                      arriving at a physical connector and
                      it being available to JACK clients

 output latency - worst case delay between writing a
                         sample to a JACK port and it emerging
                         from the corresponding physical connector

at no point in time did i suggest a value for the roundtrip latency.
the term latency has been used in such a confusing fashion by so many people
that i try to be very precise when using it now, and when i mean roundtrip or
"through" latency, i will say so. the roundtrip latency is, as you
demonstrated, NOT the
sum of the input and output latency as defined above.

> After years or providing wrong information, Jack's basic
> latency latency reporting (for HW ports) is now correct.

the information for h/w ports was never incorrect AFAIR.
the information for non-h/w ports is correct sometimes, but not others.

> Please leave it like it is.

it won't change for h/w ports. a reminder:
http://ardour.org/files/jack-latency.png shows the scheme.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
On Thu, Dec 09, 2010 at 07:16:04PM -0500, Paul Davis wrote:

> the numbers displayed are not what you are computing above.

The actual values given by jack correspond exactly to those.

> there is no display of roundtrip latency. there is only:
>
>  input latency - worst case delay between a sample
>                       arriving at a physical connector and
>                       it being available to JACK clients
>
>  output latency - worst case delay between writing a
>                          sample to a JACK port and it emerging
>                          from the corresponding physical connector

If that is your definition then the values currently provided
are wrong.

For -n 2, the worst case input latency is two periods (first
sample, for a client running just before the end of the
cycle), and the worst case output latency is also 2 periods
(last sample, for a client running at the start of the cycle).

The concept of separte input and output latency only make sense
if they refer to

- a particular sample,
- a particular time.

This is so because stored data (which is what any Jack client
uses) has by itself no time associated with it - the client
can run anywhere in the cycle and its correct operation does
not depend on that exact instant as long as it is not too
late.

The obvious choices are first sample of the period, and start
time of the period. All the others follow easily from these.
They allow to compute the effective relative time of a sample
(in or out at the physical interface) relative to 'now' for
a client running at a given time from the start of the cycle,
and for any sample. And the two values obtained that way will
always add up to the same value, which is the round-trip delay.

Any definition that leads to input + output latency not adding
up to round-trip is at best confusing, and in most cases useless.
 
> > After years or providing wrong information, Jack's basic
> > latency latency reporting (for HW ports) is now correct.
>
> the information for h/w ports was never incorrect AFAIR.
> the information for non-h/w ports is correct sometimes, but not others.

Something like five years ago, for -n 2, jack would report 1
period for input and 2 for output. I remember that very well
because I complained about it at the time. Somewhere between
then and now things changed (without announcement) to the
correct value of 1 period reported for both now.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Robin Gareus
In reply to this post by Fons Adriaensen-2

On Dec 10, 2010, at 12:31 AM, [hidden email] wrote:
>
> The actual latency values as reported by jack2 should be different
> for the standard and sync modes. If they are not that is a bug.

They are.

What I still don't understand is why JACK announces on startup
 ALSA: use 2 periods for capture
 ALSA: use 2 periods for playback

while the actual latency is
  1 period for capture  and 1 (2 for jack2 w/o --sync) periods  for playback.

or with -n3:
 ALSA: use 3 periods for capture
 ALSA: use 3 periods for playback

while the actual values are
1 period for capture and 2 (3 for jack2 w/o --sync) periods for playback.

Well, It does not really matter what JACK says at startup, as long as it works and the value reported for each port is correct..


I did not understand your comment

"For -n 2, the worst case input latency is two periods (first
sample, for a client running just before the end of the
cycle"

As long as the client produces output in the same cycle it does not matter if it runs at the start or the end of the cycle, and if it does not complete before the end of the cycle and x-run will occur. The latency will still be only 1 period.

What am I missing?

Cheers!
robin

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Paul Davis
In reply to this post by Fons Adriaensen-2
On Thu, Dec 9, 2010 at 7:52 PM,  <[hidden email]> wrote:

>>  input latency - worst case delay between a sample
>>                       arriving at a physical connector and
>>                       it being available to JACK clients
>>
>>  output latency - worst case delay between writing a
>>                          sample to a JACK port and it emerging
>>                          from the corresponding physical connector
>
> If that is your definition then the values currently provided
> are wrong.
>
> For -n 2, the worst case input latency is two periods (first
> sample, for a client running just before the end of the
> cycle),

"being available to JACK clients" was not intended to mean "all JACK clients".
Let me reword that as "being available to the JACK server" to make it clearer.

>and the worst case output latency is also 2 periods
> (last sample, for a client running at the start of the cycle).

as stated in my previous mail, it is nperiods * period_size, so we
agree here, almost. the worst case is for the *first* sample written
by a client running at the start the cycle.

one can quibble with the fact that these are asymmetric definitions,
and then provide new definitions which will conflict with the
definitions used by device driver authors, hardware manufacturers, DAW
developers, inexperienced audio engineers and a whole raft of other
people who have offered up their own definitions of what "latency"
means.

> The concept of separte input and output latency only make sense
> if they refer to
>
> - a particular sample,
> - a particular time.

i don't think this is a useful way to frame the issue.

> This is so because stored data (which is what any Jack client
> uses)

what?

> has by itself no time associated with it - the client
> can run anywhere in the cycle and its correct operation does
> not depend on that exact instant as long as it is not too
> late.

sure. all latency figures from within in a block structured graph have
period-size resolution. nothing new there.

> The obvious choices are first sample of the period, and start
> time of the period. All the others follow easily from these.

since all the samples are tightly coupled by the block-wise execution
of the graph, it really makes no difference what sample you pick as a
reference point, almost all the time. the exceptions are illustrative
but tend to confuse people.

> They allow to compute the effective relative time of a sample
> (in or out at the physical interface) relative to 'now' for
> a client running at a given time from the start of the cycle,
> and for any sample. And the two values obtained that way will
> always add up to the same value, which is the round-trip delay.

one of the reasons for the definition given below (the comment from
jack.h) is that this whole notion of "relative to "now" for a client
running at a given time" turns out to be a really horrible way to
think about this issue.

there are two situations that require an understanding of latency:

    1) attempts to synchronize with a separate clock source
    2) attempts to adjust the relative delivery of data within the
graph to compensate for latency-inducing operations at the nodes

the first one is not well supported by any of the ideas of "latency"
that we're talking about, but instead needs a system like a DLL and
timestamps. the second is well served by the definition in the jack.h
comment below, and not by any of the other definitions that you or i
have mentioned.

> Any definition that leads to input + output latency not adding
> up to round-trip is at best confusing, and in most cases useless.

you're simply wrong about this. you are free to define input or output
latency in a variety of ways, and i will not argue with any definition
you offer because i am sure it will be correct and useful. but there
is not ONLY one definition of input or output latency, and all the
different ones serve some purpose (sometimes, its selling more h/w,
sometimes its doing math).

>> > After years or providing wrong information, Jack's basic
>> > latency latency reporting (for HW ports) is now correct.
>>
>> the information for h/w ports was never incorrect AFAIR.
>> the information for non-h/w ports is correct sometimes, but not others.
>
> Something like five years ago, for -n 2, jack would report 1
> period for input and 2 for output. I remember that very well
> because I complained about it at the time. Somewhere between
> then and now things changed (without announcement) to the
> correct value of 1 period reported for both now.

what changed was the definition of the latency value returned.

/**
 * @return the time (in frames) between data being available or
 * delivered at/to a port, and the time at which it arrived at or is
 * delivered to the "other side" of the port.  E.g. for a physical
 * audio output port, this is the time between writing to the port and
 * when the signal will leave the connector.  For a physical audio
 * input port, this is the time between the sound arriving at the
 * connector and the corresponding frames being readable from the
 * port.
 */
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jack (1 and 2) latency reporting

Fons Adriaensen-2
On Thu, Dec 09, 2010 at 09:25:44PM -0500, Paul Davis wrote:

> On Thu, Dec 9, 2010 at 7:52 PM,  <[hidden email]> wrote:

> > Something like five years ago, for -n 2, jack would report 1
> > period for input and 2 for output. I remember that very well
> > because I complained about it at the time. Somewhere between
> > then and now things changed (without announcement) to the
> > correct value of 1 period reported for both now.
>
> what changed was the definition of the latency value returned.
>
> /**
>  * @return the time (in frames) between data being available or
>  * delivered at/to a port, and the time at which it arrived at or is
>  * delivered to the "other side" of the port.  E.g. for a physical
>  * audio output port, this is the time between writing to the port and
>  * when the signal will leave the connector.  For a physical audio
>  * input port, this is the time between the sound arriving at the
>  * connector and the corresponding frames being readable from the
>  * port.
>  */
>

I don't know if the definition changed but I'm 100% sure that one
of the values returned changed at some point. But forget about it,
the one jack reports today is the one I'd expect it to report, and
I certainly don't want you to change it.


The following will (I hope) clarify the matter.

You wrote (some posts ago):

> the entire latency reporting system is still in need of the overhaul i
> described months ago. however, this doesn't affect this particular
> issue, which is that the port latencies shown here should be
> (nperiods-1)*period_size and (nperiods*period_size) respectively.

which is what alarmed me and started this discussion.

Please read this again and verify if the last line is what you
intended to write. It means that the input latency depends on
the number for periods that ALSA is configured for. This is
definitely not the case, not in reality, and not according to
your definition or mine. I guess it was just a mistake.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org