|
»
« Return to Thread: jack (1 and 2) latency reporting
Re: jack (1 and 2) latency reporting
by Fons Adriaensen-2
::
Rate this Message:
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
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> 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
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
« Return to Thread: jack (1 and 2) latency reporting
| Free embeddable forum powered by Nabble | Forum Help |
