You are here

Audio slightly delayed in rare cases

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?

Forums: 
rncbc's picture

pipewire or genuine jack?

bluebell's picture

old school jack2

rncbc's picture

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

bluebell's picture

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)"?

rncbc's picture

Is it possible that Qtractor uses different timers for audio and MIDI...?

no, but you may try with jackd -c ... or, on your convenience, QjackCtl > Setup > Settings > Advanced > Clock source, what else?

br.

bluebell's picture

Thx. What MIDI clocksource will Qtractor use when set to '(default)'? The system clocksource?

rncbc's picture

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:

cat /proc/asound/timers

what actually is it using:

cat /proc/asound/seq/timer

note that only the PCM slave timers are possibly related to a specific clocksource, which you can check with:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

I believe that on most recent kernels and systems, the tsc is the default one, if not the best or only option available.

byee

bluebell's picture

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.

bluebell's picture

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.

bluebell's picture

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