On 09/03/2014 10:17 PM, Ralf Mardorf wrote:
On Wed, 2014-09-03 at 21:06 +0000, Fons Adriaensen wrote:
On Wed, Sep 03, 2014 at 10:43:35PM +0200, Ralf Mardorf wrote:
On Wed, 2014-09-03 at 20:38 +0000, Fons Adriaensen wrote:
Which, if true, would only mean that Qtractor does its latency
compensation the wrong way. Note the 'if true'.
For the versions of Qtractor I used it is true. An issue for me, because
I like to be able to use different latencies, at different work stages.
I'm aware that Ardour's latency compensation is smarter. But IMO it's
important, that Linux users who prefer session managers, at least get
informed about such issues, what ever applications they use.
There's nothing smart about it, it's not rocket science.
If Li and Lo are the current input and output latencies, then
* When recording a track, adjust the logical postion (the start offset
relative to whatever the session uses as reference) of the data by Li.
* When playing a track, adjust its logical position by Lo.
This will do the right thing, even when period sizes etc. change.
And a session manager should not try to compensate for design errors
in applications. Once you start to do that, there is no end to the
amount of misery you will cause.
Ciao,
Rui likely should know more about Qtractor's current abilities, than I
do.
qtractor does try to adjust the so called logical position or start
offset by Li as Fons explained; the Li (input latency) value is the one
given by jack_port_get_latency_range() at the time capture/recording
takes place; the actual offset is however quantized/rounded to MIDI
resolution (in ticks per quarter-note or beat)--this fact alone might
add to its "strangeness" i guess.
cheers
--
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
