It happens occasionally and unfortunately I cannot reproduce it in a sample Qtractor session. I can't reproduce it reliably in my existing sessions, either.
Sometimes the playback of audio (I think it's all audio tracks to the same amount) is a bit delayed compared to midi tracks with instrument plugin. Mostly I encounter it while wildly positioning the playhead while playback is running but it can also happen at first play after having loaded a session. I can't recognize any systematics. I have no xruns.
It seems to be the length of one buffer size and its probability seems to decrease when using big buffers and to increase when the machine is under load.
It can usually be fixed by moving the playhead to the beginning, then to the end. Sometimes just moving to the beginning fixes it. Sometimes STOP, moving the playhead before the audio clip and PLAY fixes it.
It happens with the 1000 Hz timer and the HR timer. With MIDI queue time drift correction and without.
It feels as if the audio clips would miss the correct time frame and then play on the next, staying behind as long it's playing.
Any ideas?
re. Audio slightly delayed in rare cases
pipewire or genuine jack?
old school jack2
old school jack2
re. old school jack2
then I'm clueless
if it were pipewire(-jack) I would ask to switch (jack-)transport mode to "none" or "master" only, as PW's still finicky/bad in that regard...
is very hard if not impossible to diagnose what's the issue when it's not quite reproducible.
please, keep searching for a plausible pattern and tell what you may find.
cheers
It seems to happen on one
It seems to happen on one machine only, a 10 year old Sandy Bridge Core i5. More and more I don't think it's a Qtractor bug but a timer glitch on the machine.
AFAIK the system timer is on most systems tsc but it can be set to hpet. And there is snd_hrtimer.
Is it possible that Qtractor uses different timers for audio and MIDI and how can I ensure that the same timer is always used? By setting the MIDI queue timer to "(default)"?
re. It seems to happen on one machine only...
no, but you may try with
jackd -c
... or, on your convenience, QjackCtl > Setup > Settings > Advanced > Clock source, what else?br.
Thx. What MIDI clocksource
Thx. What MIDI clocksource will Qtractor use when set to '(default)'? The system clocksource?
re. What MIDI clocksource...
in recent kernels the default is the HR timer, but it depends how it is configured at kernel build time.
to check what's available:
what actually is it using:
note that only the PCM slave timers are possibly related to a specific clocksource, which you can check with:
I believe that on most recent kernels and systems, the
tsc
is the default one, if not the best or only option available.byee
Maybe it's a hpet problem
I ran several tests and I have more and more the impression that audio wasn't delayed but MIDI was ahead.
The hpet clocksource might not be the most stable clocksource, at least on my >10 years Core i5. Maybe that's the reason why kernel 5.15 selects tsc as the clock source.
With "tsc" at system level, "(default)" in Qtractor and without "-c" in jackd I couldn't reproduce the problem anymore, neither when jumping wildly with the position marker nor when playing the song from beginning.
I have to admit that I'm
I have to admit that I'm still poking around in the fog. But even though I use native jack, switching off jack transport seems to be helpful. I have not yet been able to reproduce the problem with "none".
Yes, that's the reason why I
Yes, that's the reason why I didn't open an issue on github. As soon as I know how to reproduce it I'll open one.
I'll investigate into other
I'll investigate into other directions, too. Maybe it's important to use the same timer for Qtractor's MIDI and the Linux system. So I'll try hpet for the Linux system and Default (which means the systems timer I hope) for Qtractor's MIDI.
The problems occured with tsc for the Linux system and hpet for Qtractor's MIDI.
Add new comment