extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

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

extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Chris Caudle
OK, understanding extra latency compensation better now, but still a bit
confused by the results.  I can't seem to reconcile the results from
jack_iodelay with the track to track delays I see in Ardour 3.

On Fri, April 15, 2011 2:04 pm, Chris Caudle wrote:
> OK, so now I connected jack_delay out to the card physical output port,
then connected the card physical input port to jack_delay in, and got
this:
>
> 4155.593 frames     94.231 ms

I haven't really optimized this setup yet, so I'm running 1024
frames/period, 3 periods/buffer.

So according to jack_iodelay, the additional latency not due to the period
buffer is 3131 frames (4155 - 1024 frames per period).

So 3131 frames is about 71 ms at 44100 frames/second.  I don't see
anywhere near 71ms offset when I record one track out of Ardour, and
physically loop back to a second track in Ardour.  Does that make any
sense? Shouldn't that extra latency show up in a time offset between
tracks?
I tried using that 3131 value, and used 1566 for the values passed to the
-I and -O arguments, but it made alignment between tracks noticeably
worse.  And the delay became negative, the audio on the second track was
70 ms ahead of the first track.  That matches pretty closely the 3131
frames number, but the direction implies that the correction wasn't
needed.  How could that be?

I changed the jackd settings to use 512 frames per period, 2 periods per
buffer, and jack_iodelay reports 1595 frames latency. 1595-512 = 1083
frames "extra" latency.

I expected the "extra" latency to be due to the latency in the AD
conversion and DA conversion, and to be constant for a given sample rate.
Why such a large difference in extra latency when the period size is
changed?

These results are confounding my expectations, and I have to think that
either there is something fundamental I missed in the setup, or the test
methodology has a big hole I can't see.  Anyone else see what is going on
that I'm missing?

--
Chris Caudle







_______________________________________________
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: extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Peter Nelson-4
On Sun, 2011-04-17 at 22:33 -0500, Chris Caudle wrote:

> OK, understanding extra latency compensation better now, but still a bit
> confused by the results.  I can't seem to reconcile the results from
> jack_iodelay with the track to track delays I see in Ardour 3.
>
> On Fri, April 15, 2011 2:04 pm, Chris Caudle wrote:
> > OK, so now I connected jack_delay out to the card physical output port,
> then connected the card physical input port to jack_delay in, and got
> this:
> >
> > 4155.593 frames     94.231 ms
>
> I haven't really optimized this setup yet, so I'm running 1024
> frames/period, 3 periods/buffer.
>
> So according to jack_iodelay, the additional latency not due to the period
> buffer is 3131 frames (4155 - 1024 frames per period).
>
> So 3131 frames is about 71 ms at 44100 frames/second.  I don't see
> anywhere near 71ms offset when I record one track out of Ardour, and
> physically loop back to a second track in Ardour.  Does that make any
> sense? Shouldn't that extra latency show up in a time offset between
> tracks?
> I tried using that 3131 value, and used 1566 for the values passed to the
> -I and -O arguments, but it made alignment between tracks noticeably
> worse.  And the delay became negative, the audio on the second track was
> 70 ms ahead of the first track.  That matches pretty closely the 3131
> frames number, but the direction implies that the correction wasn't
> needed.  How could that be?
>
> I changed the jackd settings to use 512 frames per period, 2 periods per
> buffer, and jack_iodelay reports 1595 frames latency. 1595-512 = 1083
> frames "extra" latency.
>
> I expected the "extra" latency to be due to the latency in the AD
> conversion and DA conversion, and to be constant for a given sample rate.
> Why such a large difference in extra latency when the period size is
> changed?
>
> These results are confounding my expectations, and I have to think that
> either there is something fundamental I missed in the setup, or the test
> methodology has a big hole I can't see.  Anyone else see what is going on
> that I'm missing?
You're missing the periods/buffer value, and the additional period of
latency you get from JACK2's asynchronous mode.

4155 - (1024 * (3 + 1)) = 59 frames
1595 - (512 * (2 + 1)) = 59 frames

Peter.

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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Luis Garrido-4
On Mon, Apr 18, 2011 at 8:46 AM, Peter Nelson <[hidden email]> wrote:

> You're missing the periods/buffer value, and the additional period of
> latency you get from JACK2's asynchronous mode.
>
> 4155 - (1024 * (3 + 1)) = 59 frames
> 1595 - (512 * (2 + 1)) = 59 frames
>

Also USB devices will add some extra latency due to buffering in the
ALSA driver (at least one extra period or  24 ms, whichever is
shorter.) See:

http://old.nabble.com/Differences-in-latency-between-USB-and-internal-audio-interfaces-td30407033.html

Luis
_______________________________________________
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: extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Fons Adriaensen-3
In reply to this post by Chris Caudle
On Sun, Apr 17, 2011 at 10:33:58PM -0500, Chris Caudle wrote:
 
> I haven't really optimized this setup yet, so I'm running 1024
> frames/period, 3 periods/buffer.
>
> So according to jack_iodelay, the additional latency not due to the period
> buffer is 3131 frames (4155 - 1024 frames per period).

No, it is

4155 - 3 * 1024 = 1083    for jack1, or
4155 - 4 * 1024 = 59      if you use jack2 in its default mode.

 
> I changed the jackd settings to use 512 frames per period, 2 periods per
> buffer, and jack_iodelay reports 1595 frames latency. 1595-512 = 1083
> frames "extra" latency.
 
No,

1595 - 2 * 512 = 571      for jack1, or
1595 - 3 * 512 = 59       if you use jack2 in its default mode.


These results make me think that you are indeed using jack2 in its
default mode wich adds 1 extra period of latency.

> I expected the "extra" latency to be due to the latency in the AD
> conversion and DA conversion, and to be constant for a given sample rate.
> Why such a large difference in extra latency when the period size is
> changed?
>
> These results are confounding my expectations, and I have to think that
> either there is something fundamental I missed in the setup, or the test
> methodology has a big hole I can't see.  Anyone else see what is going on
> that I'm missing?

You are missing the correct way to calculate the extra latency.

   measured_latency - n * p           for jack1 or
   measured_latency - (n + 1) * p     for jack2 in its default mode.

where n and p are the values given to the -n and -p options.

Ciao,

--
FA


_______________________________________________
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: extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Clemens Ladisch
In reply to this post by Luis Garrido-4
Luis Garrido wrote:

> On Mon, Apr 18, 2011 at 8:46 AM, Peter Nelson <[hidden email]> wrote:
> > You're missing the periods/buffer value, and the additional period of
> > latency you get from JACK2's asynchronous mode.
> >
> > 4155 - (1024 * (3 + 1)) = 59 frames
> > 1595 - (512 * (2 + 1)) = 59 frames
>
> Also USB devices will add some extra latency due to buffering in the
> ALSA driver (at least one extra period or  24 ms, whichever is
> shorter.)

But only for PCM devices; USB MIDI data is not scheduled for some future
time but can be sent at once.


Regards,
Clemens
_______________________________________________
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: extra latency compensation was Re: is this latency coming from ALSA, jack, or ardour?

Paul Davis
In reply to this post by Chris Caudle
On Sun, Apr 17, 2011 at 11:33 PM, Chris Caudle <[hidden email]> wrote:
> OK, understanding extra latency compensation better now, but still a bit
> confused by the results.  I can't seem to reconcile the results from
> jack_iodelay with the track to track delays I see in Ardour 3.

i've already mentioned that there are bugs with this in all released
ardour versions.

you will not get a3 doing the right thing UNLESS you disconnect a
"source" track from all other JACK ports when re-recording it to a new
track. i'm not going to explain why this is occuring - its a bug and
it will be fixed, likely in the next several days. ardour will do the
"right" thing if you switch the new track alignment to "capture time".

> So according to jack_iodelay, the additional latency not due to the period
> buffer is 3131 frames (4155 - 1024 frames per period).

this is not correct. my original instructions were more correct. i
will modify jack_iodelay to print a more informative set of output
than it currently does.

> I expected the "extra" latency to be due to the latency in the AD
> conversion and DA conversion, and to be constant for a given sample rate.
> Why such a large difference in extra latency when the period size is
> changed?

its definitely not always constant w.r.t sample rate. it depends on
the nature of the converters used.
_______________________________________________
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: extra latency compensation

Chris Caudle
In reply to this post by Fons Adriaensen-3
On Mon, April 18, 2011 4:35 am, Fons Adriaensen wrote:
> You are missing the correct way to calculate the extra latency.
>
>    measured_latency - n * p           for jack1 or
>    measured_latency - (n + 1) * p     for jack2 in its default mode.

Fons, thank you, that seems to have corrected the problems I was having.
At least with my PCI interface, the USB seems to have other problems not
related to this calculation.

The man page for jack_iodelay that comes with jack is currently incorrect.
 There is also no documentation that I could find which explains the
process of latency compensation, so I think I will try to write up a
correction for the man page to submit a patch, and perhaps a tutorial on
latency correction later in the week.

> These results make me think that you are indeed using jack2 in its
> default mode wich adds 1 extra period of latency.

Yes, I had forgotten about the 1 extra period with jack2.  I am using
qjackctl for convenience in displaying and setting jack parameter, and
that tool does not make visible the synchronous or asynchronous option
since the option is not common between jack1 and jack2.

--
Chris Caudle


_______________________________________________
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: extra latency compensation

Chris Caudle
In reply to this post by Paul Davis
On Mon, April 18, 2011 12:10 pm, Paul Davis wrote:
> i've already mentioned that there are bugs with this in all released
> ardour versions.

Yes, but the corrected instructions from Fons seem to make my PCI
interface behave as expected.  After recording the click to track 1 via
analog loop back, I could not distinguish between the generated click
track, and the recording of the click playing back from track 1. I bounced
the recorded track to track 2, bounced track 2 to track 3, etc. via analog
loop back until I had 10 tracks, and I could unmute any of the 10 tracks
while track 1 or the generated click track was playing, and not hear an
offset.  As far as I can tell, with my PCI card, the compensation is
effectively perfect now.

> you will not get a3 doing the right thing UNLESS you disconnect a
> "source" track from all other JACK ports when re-recording it to a new
> track.

OK, if you say so, but it seems to work for me.  The input of each track
was connected to the card physical input ports, and the output of each
track went to the master bus.

> ardour will do the "right" thing if you switch the new track
>  alignment to "capture time".

That made the alignment much worse when I tried it.

The disturbing part, after getting the latency compensation working
effectively perfectly for my PCI card, is that my USB interface is
inconsistent in a way that I think jack cannot be involved.  I used the
same process as for my PCI card, but with my USB interface, and the first
5 tracks aligned perfectly, then the 6th and subsequent tracks diverged by
about 1ms per track (audio for later tracks being aligned earlier in time
than the first tracks).  I tried exactly the same process again on a new
session, and that time the 1st track was ahead of the click by about
0.75ms, the second track was ahead of the first by about 0.25ms.  The 10th
track ended up ahead of the generated click by about 8 ms.

I created a third session and did the same things again, but this time
each track had the alignment set to align with capture time, and each
track was delayed 77ms relative to the previous track.  The 10th track
ended up 775 ms after the nominal beat/generated click, or about 700 ms
delayed relative to the first recorded track.  That definitely wasn't what
I wanted.

The difference in results between the PCI card and the USB interface, and
the fact that the USB interface wasn't consistent from session to session,
or even track to track within a session, makes me think that there is just
something off in the USB stack.  I only have the one USB interface, I
suppose my hardware could just be broken in some weird way that only
affects latency, or a bug in the device firmware.  I would want to compare
results with someone who has different USB hardware first, I guess.

So to come all the way back to the way my original question was posed, I
think the answer (to where is the extra uncompensated latency coming from)
is:

I did not understand the way latency is communicated, I thought ALSA would
provide a latency number for an interface, but you actually have to
measure it yourself.

The way you measure that latency is with the tool jack_iodelay (which is
not currently mentioned anywhere on the jack web site).

After you measure the latency with jack_iodelay, you have to massage the
returned data in a way that does not match the current man page to get
accurate results.  Additionally, you have to keep in mind the additional
period of latency added by jack2 asynchronous mode.

And on top of all that, USB still seems screwy, at least with my hardware.
 I would be interested to hear results from others with USB hardware,
especially if they can get good results.

--
Chris Caudle


_______________________________________________
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: extra latency compensation

Paul Davis
On Tue, Apr 19, 2011 at 12:14 AM, Chris Caudle <[hidden email]> wrote:

>I did not understand the way latency is communicated, I thought ALSA would
>provide a latency number for an interface, but you actually have to
>measure it yourself.

ALSA can't know this. Determining the number requires the user
establishes a loopback signal path, which clearly can't be assumed at
any point during driver initialization, setup, or what have you.
Remember that for any digital out, the converters don't even live on
the audio interface itself, so even if there was a standard protocol
to discover "physical latency of the soundcard" it would fail for
digital signal paths since it would rely on components not connected
via the PCI bus.

--p
_______________________________________________
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: extra latency compensation (USB interfaces)

Chris Caudle
In reply to this post by Luis Garrido-4
On Mon, April 18, 2011 2:53 am, Luis Garrido wrote:
> Also USB devices will add some extra latency due to buffering in the
> ALSA driver (at least one extra period or  24 ms, whichever is
> shorter.) See:

Yes, but that extra latency should be compensated when measured with
jack_iodelay and passed to jack via the -I and -O options, should it not?

--
Chris Caudle


_______________________________________________
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: extra latency compensation

Clemens Ladisch
In reply to this post by Chris Caudle
Chris Caudle wrote:
> The difference in results between the PCI card and the USB interface, and
> the fact that the USB interface wasn't consistent from session to session,
> or even track to track within a session, makes me think that there is just
> something off in the USB stack.

In addition to the already mentioned USB queueing delay (up to 24 ms,
depending on the period size), USB also adds a somewhat random delay
between the playback and capture streams.  The USB host controller
drivers do not implement the support for scheduling streams at
a specific time, so the offset between both streams might be one
millisecond if the second stream start occurred one frame later, plus
any delays due to executing the code.

> I only have the one USB interface, I suppose my hardware could just be
> broken in some weird way that only affects latency, or a bug in the
> device firmware.  I would want to compare results with someone who has
> different USB hardware first, I guess.

It is not possible for the USB hardware or the device firmware to affect
the latency in any meaningful way; all these latencies can be explained
by known deficiencies in the Linux USB stack.


Regards,
Clemens
_______________________________________________
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: extra latency compensation

Stéphane Letz
In reply to this post by Paul Davis

Le 19 avr. 2011 à 06:20, Paul Davis a écrit :

> On Tue, Apr 19, 2011 at 12:14 AM, Chris Caudle <[hidden email]> wrote:
>
>> I did not understand the way latency is communicated, I thought ALSA would
>> provide a latency number for an interface, but you actually have to
>> measure it yourself.
>
> ALSA can't know this. Determining the number requires the user
> establishes a loopback signal path, which clearly can't be assumed at
> any point during driver initialization, setup, or what have you.
> Remember that for any digital out, the converters don't even live on
> the audio interface itself, so even if there was a standard protocol
> to discover "physical latency of the soundcard" it would fail for
> digital signal paths since it would rely on components not connected
> via the PCI bus.
>
> --p
> _______________________________________________

I'm wondering now how they do on OSX, since interfaces can be asked for their "input latency", "input latency offset", "output latency", "output latency offset".

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: extra latency compensation

Paul Davis
On Tue, Apr 19, 2011 at 2:59 AM, Stéphane Letz <[hidden email]> wrote:

> I'm wondering now how they do on OSX, since interfaces can be asked for their "input latency", "input latency offset", "output latency", "output latency offset".

Yes, you can do this for devices with their own A/D and D/A. it
doesn't work AFAIK if you use external converters.
_______________________________________________
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: extra latency compensation

Chris Caudle
In reply to this post by Chris Caudle
On Tue, April 19, 2011 1:05 am, Clemens Ladisch wrote:
> In addition to the already mentioned USB queueing delay
> (up to 24 ms, depending on the period size)

Is that constant?  If so, it should get calibrated out by using the
jack_iodelay measurements, right?

> USB also adds a somewhat random delay
> between the playback and capture streams.

That is disappointing.
Why have I not run across this information before?  I would have thought
that a lot of musicians would have been complaining about random time
offsets when overdubbing.
Or is it +/-1ms worst case?  If that is the limit, then probably it is not
noticeable in most cases.  If the delay stays constant once the stream is
started, I think it should be roughly equivalent to moving a microphone 1
ft/0.3m farther away from an acoustic instrument, and I think no one would
complain about that.

> all these latencies can be explained by known deficiencies
> in the Linux USB stack.

The general USB stack used by all applications, or specifically the USB
audio device support?  Is the deficiency something that can be corrected
in ALSA code, or would have to be addressed in the general USB support in
the Linux kernel?

Maybe this is all much ado about nothing.  I think I'll just lay down some
drum tracks on a night when I haven't had beer and see if it matters.
Maybe close is good enough.

--
Chris Caudle


_______________________________________________
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: extra latency compensation

Clemens Ladisch
Chris Caudle wrote:
> On Tue, April 19, 2011 1:05 am, Clemens Ladisch wrote:
> > In addition to the already mentioned USB queueing delay
> > (up to 24 ms, depending on the period size)
>
> Is that constant?

Yes.

> If so, it should get calibrated out by using the jack_iodelay
> measurements, right?

Yes.

> > USB also adds a somewhat random delay
> > between the playback and capture streams.
>
> Or is it +/-1ms worst case?

In practice, yes.

> > all these latencies can be explained by known deficiencies
> > in the Linux USB stack.
>
> The general USB stack used by all applications, or specifically the USB
> audio device support?  Is the deficiency something that can be corrected
> in ALSA code, or would have to be addressed in the general USB support in
> the Linux kernel?

It would be possible to add some workarounds in the audio driver, but
doing this right in the USB stack would be easier.


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