Forums
This can be improved, I think. I set up a loopback in my audio interface.
jackd -p1024 -n3
Qtractor compensated the recorded audio clip with an offset of 2050 frames
jackd -p1024 -n3 -I80 -O80 (as recommended by jack_iodelay)
Qtractor compensated the recorded audio clip with an offset of 2125 frames
In both cases jack_iodelay reported 4250 frames. Using this as the audio clip's offset did the job.
1.) Can the accuracy of the value that is automatically determined by Qtractor be improved?
2.) I propose a configuration option in View->Options-Audio so I can choose between "automatic" and "manual". When choosing "manual" I can enter the offset in frames. Maybe in frames, BBT and ms as in audio clips.
File attachments
I'm not sure if this is…
I'm not sure if this is related.
Are you using input-only or duplex buses? Input-only buses only provide half compensation, which is optimal for recording applications (where only half compensation is needed, just audio output, since there's no input). Duplex buses provide double compensation, which is optimal for recording external audio.
recording from duplex bus
Recording from a duplex bus leads to a different offset that Qtractor adds: 3075
I wouldn't have expected that.
But still not enough. It should be much larger.
So I think an option to set it manually in View->Options->Audio would be very helpful.
Hardware latency
But the latency you're mentioning seems to be more related to the sound card hardware (DAC and ADC). Wouldn't it be more convenient to modify it there, in the audio engine?
This is for Pipewire, but I assume ALSA has tools for this. Since it's at the hardware level, it would also affect Jack.
https://pipewire-pages-freedesktop-org.translate.goog/wireplumber/daemon/configuration/alsa.html?_x_tr_sl=auto&_x_tr_tl=es&_x_tr_hl=es#alsa-extra-latency-properties
The Cable configuration manager for Pipewire includes a tool for this.
On my system, I don't see that much difference. I ran the Cable test, and the sound card shows 0 latency. It starts with a delay, but after a second or two of establishing the input-to-output connection, it stabilizes at 0. Therefore, considering that the connections are established in Qtractor at the beginning of the session, the delay occurs during those loading seconds, but I don't experience this delay while working with it.
In conclusion, my system doesn't require any additional corrections, and if it does, I believe the problem lies with the system itself, not Qtractor.
However, I'm quite ignorant about these topics, so I might be mistaken. I'm only mentioning this to help, not because I have anything against including this functionality.
Test it
As there is no such hardware that converts digital to anlog and back without additional latency it's not possible to determine the latency only from software parameters like buffer size and number of buffers.
Play a track with percussive stuff - e.g. from my attached sample session - and record it back with a connection from your audio adapter's output to its input. I would be surprised if original and recorded tracks were in perfect sync.
re. Test it (PS 2)
I tested it by routing the output and input with a physical cable. I was surprised.
I have to edit the offset to 0 in the clip for alignment.
That is, with the integrated sound card in my computer and Pipewire, the offset that Qtractor performs isn't necessary (in fact, it's counterproductive). I suppose this is because Pipewire has already performed it.
As I said, all of this is beyond me due to its complexity.
Another surprise: there are still misalignments when the loop is activated, despite having a standard kernel and no audio configuration.
However, with the standard kernel, the misalignments between tracks in playbacks without loops disappeared.
PS
My test indicates that you were right; the place where the user should be able to specify the compensation is in the recorder, in this case Qtractor, thus bringing order to all the different latencies and compensations that can arise from different combinations of sound cards, kernels, audio engines, etc.
PS 2
Another curious thing.
jack_iodelay gave you 4250, and that was correct. I got 0 (the latency tool in Cable is just an interface for jack_iodelay), and that was correct too.
one step after another
If you activate the loop in my attached sample session then the compensated audio clip gets more unsynced with every iteration. But I recommend that the first low hanging fruit is a configuration option in View->Options->Audio for a manually set audio clip's offset that's applied after recording. It's always a good idea to give maximum control to the user.
The loop issue might be buried deep in the code. Some of this kind of issues can be fixed by automating a mute/unmute before the clips which forces a realignment.
re. Audio clip recording latency compensation...
yes, we can try to improve on this... check qtractor >= 1.5.9.13git.9c5ea2
not this time so close to EoY'25, maybe later, perhaps...
cheers
re. re. Audio clip recording latency compensation...
This is nearly perfect.
jack_iodelay determines 4265. As I have learned it's not a stable value across computer restarts because of USB's pitfalls. When I did it the last time I got 4250 which seems reasonable.
This improvement in Qtractor even takes the jackd parameter -I or -O into account.
With omitting -I and -O Qtractor sets an offset of 4100. Not bad.
After using -I 80 -O 80 as jack_iodelay recommends Qtractor set an offset of 4175. That's even better.
Is it possible that you considered only one of the pair -I/-O? Because you would determine the perfect value 4250 if you would add another 75.
good enough...
is fair enough, for now.
keep testing and report any critical findings, will you?
otoh. jackd might have these -I/-O tunings but I'm afraid PW have not, at least without delving into some obscure configs so we'll leave it there for now :)
cheers && thanks
I think you didn't get the additional output hardware latency
I ran some more tests with genuine jack2:
So for me it looks like you're getting the additional input latency (-I) but not the additional output latency (-O).
re. the additional output hardware latency...
is not being taken into account just because we're dealing with input (recording) latency compensation alone...
getting it to know whether you're recording a full round-trip signal is hard, to say the least; it can only assume you're recording an external input (mic, line-in, etc.) or from an internal app/client that is connected in... and not anything that you may send to line-out then feedback to line-in, and account for the whole round-trip anyway.
qtractor, jackd or pipewire for that matter, can only guess or better estimate the input/capture latency because that's the only graph path it may only know for sure (from where it's being fed anyway)
hth.
ps. in you particular case then (jackd) you may please tinker with the -I parameter alone: say -I 160 ?
re. re. the additional output hardware latency...
I can double the input latency to trick out Qtractor.
But I can't follow your arguments since you did take into account the latency of the 3 output buffers. So you have to take into account the output hardware latency as well. Then you got the whole round trip latency.
Now: 1024 * 3 + 1024 + 80 = 4176
Should be: 1024 * 3 + 80 + 1024 + 80 = 4256
(plus/minus some jack rounding errors)
Add new comment