|
»
« Return to Thread: jack (1 and 2) latency reporting
Re: jack (1 and 2) latency reporting
by Paul Davis
::
Rate this Message:
On Thu, Dec 9, 2010 at 7:52 PM, <fons@...> 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
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>> 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
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 |
