4 Sep
2014
4 Sep
'14
11:05 p.m.
On 09/04/2014 09:33 PM, Ralf Mardorf wrote:
-------- Forwarded Message --------From: Ralf Mardorf
<ralf.mardorf(a)rocketmail.com>
To: qtractor-devel(a)lists.sourceforge.net
Subject: Re: [Qtractor-devel] ; ) Was - Re: [LAU] Session management
with NSM
Date: Thu, 04 Sep 2014 22:31:15 +0200
Mailer: Evolution 3.12.5
On Thu, 2014-09-04 at 21:27 +0100, Rui Nuno Capela wrote:
and why would that be interesting?
qtractor does its "recording/input latency compensation" of audio cľips
*at the time* the audio material is captured, so that material gets
aligned with the audio/MIDI content already in session and possibly
being played back at the time of the recording. never again it gets
adjusted no matter what jackd parameters change later, be that for worse
or better. that's it.
please understand that this is the only kind of latency compensation
qtractor does and nothing else. nb. qtractor does NOT compensate for
in-line output or plugin chain latency. never did and quite frankly it
won't do so soon, i'm afraid.
i really don't see how having distinct jackd i/o latency settings
(buffer-size, periods, sample-rate) may lead to audio going out of sync
to MIDI--if it does get out-of-sync anyway, it is probably because
something else but latency compensation related, not to tell that
session-management has nothing to do with either.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
ps. if audio and MIDI get out of sync, timer type and/or resolution
might be the top suspect.
On 09/04/2014 07:49 PM, Ralf Mardorf wrote:
It doesn't report the latency a session was recoded 2 years ago.
Rui :)
please consider to automatically add to
File > Properties ... > Description
the jackd "in" and "out" reported latency ;). Since the MIDI
resolution
steps don't provide ms, frame information, a written note could help to
fix sync problems, without using a calculator.
(I don't need it, perhaps you could add an option to the preferences, to
uncheck this feature ;)
jack_lsp -l does report latency of every port
byee 
4 Sep
4 Sep
11:34 p.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On Thu, 2014-09-04 at 22:05 +0100, Rui Nuno Capela wrote:
On 09/04/2014 09:33 PM, Ralf Mardorf wrote:
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts jackd
with a lower I+O latency. Nothing bad would happen for Ardour users, but
a Qtractor user would run into sync issues. Am I mistaken?
-------- Forwarded Message --------From: Ralf
Mardorf
<ralf.mardorf(a)rocketmail.com>
To: qtractor-devel(a)lists.sourceforge.net
Subject: Re: [Qtractor-devel] ; ) Was - Re: [LAU] Session management
with NSM
Date: Thu, 04 Sep 2014 22:31:15 +0200
Mailer: Evolution 3.12.5
On Thu, 2014-09-04 at 21:27 +0100, Rui Nuno Capela wrote:
and why would that be interesting?
qtractor does its "recording/input latency compensation" of audio cľips
*at the time* the audio material is captured, so that material gets
aligned with the audio/MIDI content already in session and possibly
being played back at the time of the recording. never again it gets
adjusted no matter what jackd parameters change later, be that for worse
or better. that's it.
please understand that this is the only kind of latency compensation
qtractor does and nothing else. nb. qtractor does NOT compensate for
in-line output or plugin chain latency. never did and quite frankly it
won't do so soon, i'm afraid.
i really don't see how having distinct jackd i/o latency settings
(buffer-size, periods, sample-rate) may lead to audio going out of sync
to MIDI--if it does get out-of-sync anyway, it is probably because
something else but latency compensation related, not to tell that
session-management has nothing to do with either. On 09/04/2014 07:49 PM, Ralf Mardorf wrote:
It doesn't report the latency a session was recoded 2 years ago.
Rui :)
please consider to automatically add to
File > Properties ... > Description
the jackd "in" and "out" reported latency ;). Since the MIDI
resolution
steps don't provide ms, frame information, a written note could help to
fix sync problems, without using a calculator.
(I don't need it, perhaps you could add an option to the preferences, to
uncheck this feature ;)
jack_lsp -l does report latency of every port
byee
5 Sep
5 Sep
12:11 a.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On 09/04/2014 10:34 PM, Ralf Mardorf wrote:
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts jackd
with a lower I+O latency. Nothing bad would happen for Ardour users, but
a Qtractor user would run into sync issues. Am I mistaken?
i really don't get why it would have worse or better sync depending on
jackd latency settings. please forgive me, but i don't see it directly
related to the case of audio vs. midi sync...
though, in the special case that comes to mind, iif the alsa-midi timer
is slaved to a pcm sound-device, as against to the system or hires timer
for instance, you probably will get it different whether running on
disparate buffer-sizes, periods and/or sample-rates, that's for
granted--well, if you change the sample-rate across sessions you will
get prompted to convert into a brand new and different session anyhow ;)
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
3:19 a.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On 05/09/14 03:56, Rui Nuno Capela wrote:
On 09/04/2014 10:34 PM, Ralf Mardorf wrote:
Huh??
So you have audio coming from the PC and MIDI going out to external
sound generating MIDI devices and you don't see how output latency from
the computer can affect the timing sync between sound from the computer
and sound from the audio modules??? Surely even a blind wombat could see
that! Unless there is some magic in Jack/AlsaMIDI which automagically
delays the MIDI by the same as the output buffer settings of Jack. Then
some might also want to add a fixed delay value to take into account the
hardware delay (propagation time) but I think we really are getting a
bit complex now!
Although I very much doubt anybody would be able to hear the difference
if you're only talking a couple of ms and have different sounds both
internally and externally (same sounds would cause comb filtering and
eventually echo once latency became high enough.)
But this is true for ALL audio coming out of the sequencer, whether you
recorded it or it's from a sample-pack or a soft-synth etc etc.
tl/dr: All that is really needed is an option to delay MIDI signals by
the amount of the audio output buffer (plus you could add the optional
hardware delay in settings if you really wished). This should bring
output of both audio and MIDI sounds as close to sync as is possible,
with the real-world systems being as imperfect as they are.
Dale.
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts jackd
with a lower I+O latency. Nothing bad would happen for Ardour users, but
a Qtractor user would run into sync issues. Am I mistaken?
i really don't get why it would have worse or better sync depending on
jackd latency settings. please forgive me, but i don't see it directly
related to the case of audio vs. midi sync...
though, in the special case that comes to mind, iif the alsa-midi
timer is slaved to a pcm sound-device, as against to the system or
hires timer for instance, you probably will get it different whether
running on disparate buffer-sizes, periods and/or sample-rates, that's
for granted--well, if you change the sample-rate across sessions you
will get prompted to convert into a brand new and different session
anyhow ;)
byee
3:33 a.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On 05/09/14 03:56, Rui Nuno Capela wrote:
On 09/04/2014 10:34 PM, Ralf Mardorf wrote:
Huh??
So you have audio coming from the PC and MIDI going out to external
sound generating MIDI devices and you don't see how output latency from
the computer can affect the timing sync between sound from the computer
and sound from the audio modules??? Surely even a blind wombat could see
that! Unless there is some magic in Jack/AlsaMIDI which automagically
delays the MIDI by the same as the output buffer settings of Jack. Then
some might also want to add a fixed delay value to take into account the
hardware delay (propagation time) but I think we really are getting a
bit complex now!
Although I very much doubt anybody would be able to hear the difference
if you're only talking a couple of ms and have different sounds both
internally and externally (same sounds would cause comb filtering and
eventually echo once latency became high enough.)
But this is true for ALL audio coming out of the sequencer, whether you
recorded it or it's from a sample-pack or a soft-synth etc etc.
tl/dr: All that is really needed is an option to delay MIDI signals by
the amount of the audio output buffer (plus you could add the optional
hardware delay in settings if you really wished). This should bring
output of both audio and MIDI sounds as close to sync as is possible,
with the real-world systems being as imperfect as they are.
Dale.
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts jackd
with a lower I+O latency. Nothing bad would happen for Ardour users, but
a Qtractor user would run into sync issues. Am I mistaken?
i really don't get why it would have worse or better sync depending on
jackd latency settings. please forgive me, but i don't see it directly
related to the case of audio vs. midi sync...
though, in the special case that comes to mind, iif the alsa-midi
timer is slaved to a pcm sound-device, as against to the system or
hires timer for instance, you probably will get it different whether
running on disparate buffer-sizes, periods and/or sample-rates, that's
for granted--well, if you change the sample-rate across sessions you
will get prompted to convert into a brand new and different session
anyhow ;)
byee
10:25 a.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On 2014-09-05 02:32, Kazakore wrote:
On 05/09/14 03:56, Rui Nuno Capela wrote:
re. external midi equipment, probably yes, that might be pertinent,
but...
my point was about audio and midi sync within qtractor (the sequencer)
internally. once midi gets out of the sequencer or even of the machine,
then i doubt one can ever compensate effectively for the delay, drift or
jitter that will be always present, no mater how small but orthogonal to
jackd buffer-size, periods or sample-rate, whatever, and sure matters to
a perfect sync. i doubt the output latency of the in-machine jack-audio
graph might be any significant or functional to that goal.
On 09/04/2014 10:34 PM, Ralf Mardorf wrote:
Huh??
So you have audio coming from the PC and MIDI going out to external
sound generating MIDI devices and you don't see how output latency
from the computer can affect the timing sync between sound from the
computer and sound from the audio modules??? Surely even a blind
wombat could see that! Unless there is some magic in Jack/AlsaMIDI
which automagically delays the MIDI by the same as the output buffer
settings of Jack. Then some might also want to add a fixed delay value
to take into account the hardware delay (propagation time) but I think
we really are getting a bit complex now!
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't
remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts
jackd
with a lower I+O latency. Nothing bad would happen for Ardour users,
but
a Qtractor user would run into sync issues. Am I mistaken?
i really don't get why it would have worse or better sync depending on
jackd latency settings. please forgive me, but i don't see it directly
related to the case of audio vs. midi sync...
though, in the special case that comes to mind, iif the alsa-midi
timer is slaved to a pcm sound-device, as against to the system or
hires timer for instance, you probably will get it different whether
running on disparate buffer-sizes, periods and/or sample-rates, that's
for granted--well, if you change the sample-rate across sessions you
will get prompted to convert into a brand new and different session
anyhow ;)
byee Although I very much doubt anybody would be able to
hear the
difference if you're only talking a couple of ms and have different
sounds both internally and externally (same sounds would cause comb
filtering and eventually echo once latency became high enough.)
exactly :)
But this is true for ALL audio coming out of the
sequencer, whether
you recorded it or it's from a sample-pack or a soft-synth etc etc.
tl/dr: All that is really needed is an option to delay MIDI signals by
the amount of the audio output buffer (plus you could add the optional
hardware delay in settings if you really wished). This should bring
output of both audio and MIDI sounds as close to sync as is possible,
with the real-world systems being as imperfect as they are.
cheers
--
rncbc aka. Rui Nuno Capela
5:40 p.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On 05/09/14 14:08, Rui Nuno Capela wrote:
Plus (extrapolating from Ralf's comments) you clearly do already provide
a way for the adjustment to be done manually! Even if it is harder work
for the user...
On 2014-09-05 02:32, Kazakore wrote:
I should probably drop out of this conversation as I haven't used
QTractor nor have I used any external gear for quite some time. But if
the issue is with external then you also need to bear in mind that you
might send some internally and some externally, so applying the same
delay to everything will still put some parts out of time with others. A
toggle for a MIDI channel going to int/ext could possibly be one solution??
Or if it is related to internal audio ssync I have to admit I am also
stumped why this would happen, as all audio coming out of the computer
would be going through the same audio buffers (Jack) and delayed the
same amount!
On 05/09/14 03:56, Rui Nuno Capela wrote:
re. external midi equipment, probably yes, that might be pertinent,
but...
my point was about audio and midi sync within qtractor (the sequencer)
internally. once midi gets out of the sequencer or even of the
machine, then i doubt one can ever compensate effectively for the
delay, drift or jitter that will be always present, no mater how small
but orthogonal to jackd buffer-size, periods or sample-rate, whatever,
and sure matters to a perfect sync. i doubt the output latency of the
in-machine jack-audio graph might be any significant or functional to
that goal.
On 09/04/2014 10:34 PM, Ralf Mardorf wrote:
Huh??
So you have audio coming from the PC and MIDI going out to external
sound generating MIDI devices and you don't see how output latency
from the computer can affect the timing sync between sound from the
computer and sound from the audio modules??? Surely even a blind
wombat could see that! Unless there is some magic in Jack/AlsaMIDI
which automagically delays the MIDI by the same as the output buffer
settings of Jack. Then some might also want to add a fixed delay value
to take into account the hardware delay (propagation time) but I think
we really are getting a bit complex now!
This year You record an audio track with an I+O latency of 10.7 ms.
Two year later you want to restore this session, but you don't
remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts
jackd
with a lower I+O latency. Nothing bad would happen for Ardour
users, but
a Qtractor user would run into sync issues. Am I mistaken?
i really don't get why it would have worse or better sync depending
on jackd latency settings. please forgive me, but i don't see it
directly related to the case of audio vs. midi sync...
though, in the special case that comes to mind, iif the alsa-midi
timer is slaved to a pcm sound-device, as against to the system or
hires timer for instance, you probably will get it different whether
running on disparate buffer-sizes, periods and/or sample-rates,
that's for granted--well, if you change the sample-rate across
sessions you will get prompted to convert into a brand new and
different session anyhow ;)
byee Although I
very much doubt anybody would be able to hear the
difference if you're only talking a couple of ms and have different
sounds both internally and externally (same sounds would cause comb
filtering and eventually echo once latency became high enough.)
exactly :)
7:30 p.m.
New subject: [Bulk] Re: [Qtractor-devel] [Fwd: Re: ; ) Was - Re: Session management with NSM]
On Thu, Sep 04, 2014 at 11:34:27PM +0200, Ralf Mardorf wrote:
This year You record an audio track with an I+O
latency of 10.7 ms.
Two year later you want to restore this session, but you don't remember
the jackd settings you used. Originally audio and MIDI tracks were in
sync, when you used 10.7 ms I+O latency. Within the years you got new
hardware, you don't remember what latency you once used and starts jackd
with a lower I+O latency. Nothing bad would happen for Ardour users, but
a Qtractor user would run into sync issues. Am I mistaken?
No.
If you use different HW, latency will change even if you use the
same Jack settings, but it shouldn't matter. At least not if the
SW does the right thing, which is to store all positions on the
timeline in a way that makes them independent of latency, i.o.w.
as they would have been if there were no latency. All that takes
is is to correct for input latency when recording, and for output
latency when playing, in both cases using the actual values which
don't even have to be remembered. It's simple enough, there is no
excuse for getting it wrong.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
3529
days inactive
3530
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Fons Adriaensen -
Kazakore -
Ralf Mardorf -
Rui Nuno Capela