Forums
Hey, it's me, the nitpicker again. And I hope I have finally an issue regarding audio clip position in time that's easily reproducable.
- New Qtractor session
- New audio track with a big clip, e.g. a whole song
- Duplicate this track a few times
- Set a left and right marker for a loop
- Play the song
- Toggle loop on and off, both within the loop and outside the loop
See if you get the same phasing effect or missing audio output of some tracks.
If not, because your computer is fast, then disable all your CPU cores but one. I added two bash scripts that are to be called via sudo or as root.
And set the governor to powersave with the attached script: sudo setgovernor.sh powersave
Expected results: see screencast. It's too big to be uploaded so please use
http://suedwestlicht.saar.de/secdnld/clipsymc-2025-09-27_17.47.12.mkv
File attachments
re. Clips not in sync, now reproducible...
hi, thanks for the heads up...
as it seems this is probably to system condition and probable thread overload, leading to one or more sync point misses that may certainly occur under stress conditions..
fixing or even mitigating these issues is dang hard I'm afraid and would need an almost complete architecture overhaul or rewrite.
sorry to tell, that is not in the plans, not even beyond the horizon, so to speak--it's the kind of software problem that might get only solved by throwing more hardware to it :)
cheers
Maybe priorize/tune?
There's not always a shortage on CPU, especially on realtime CPU on my machine, when it occurs. Could this – I'd call it – setup task that's called whenever (I guess) the playhead is repositioned or loop on/off is clicked be priorized? Qtractor's GUI is not using realtime priority, and that's good. But other tasks do. Since this setup task is so crucial, can it be priorized?
That would make sure that it gets the CPU it needs – or the computer is obviously much too slow.
another approach
I noticed that the phasing is fixed while playing when all the audio tracks are selected and I mute and unmute them.
So I think it would be interesting to see if the following modification (maybe in another branch) will stabilize it:
Whenever the loop is acivated or deactivated OR the playhead is repositioned¹ then
for all audio tracks that are not muted
mute track and unmute track
1.) e̵x̵c̵e̵p̵t̵ ̵w̵h̵e̵n̵ ̵t̵h̵e̵ ̵r̵e̵p̵o̵s̵i̵t̵i̵o̵n̵i̵n̵g̵ ̵h̵a̵p̵p̵e̵n̵s̵ ̵b̵e̵c̵a̵u̵s̵e̵ ̵t̵h̵e̵ ̵p̵l̵a̵y̵h̵e̵a̵d̵ ̵r̵e̵a̵c̵h̵e̵s̵ ̵t̵h̵e̵ ̵l̵o̵o̵p̵'̵s̵ ̵e̵n̵d̵ ̵a̵n̵d̵ ̵j̵u̵m̵p̵s̵ ̵t̵o̵ ̵t̵h̵e̵ ̵l̵o̵o̵p̵'̵s̵ ̵s̵t̵a̵r̵t̵
If this helps then it could be considered to be configurable, similar to view->options->MIDI->reset all controllers on playback start,
maybe view->options->Audio->reset all audio tracks on playback start
EDIT:
I got audio clips out of sync when loop jumped to the start as well if the audio clip started before loop's start.
How does Qtractor calculate the loop?
Although it's a minor issue, it can be annoying.
The reason for the desynchronization may be how the loop is calculated, whether by time or by samples.
If it's by time, the samples won't match, and the offset can be cumulative, as I believe it is.
1 millisecond is equivalent to 46 samples in my setup. This is enough to cause unwanted clicks, and over dozens of cycles, things start to sound out of sync.
It's just a hypothesis.
Timer setting? [edited: 1, 2,3]
I've set the timer to PCM PLAY 0-3-0 in the options, and that seems to fix it.
If this is the case, which option is best for working with audio and MIDI?
[Edited 1
It may have nothing to do with it, I just can't reproduce the problem with any settings in a session that was previously problematic... well, a mystery.
]
[Edited 2
The problem becomes more evident when the start and end of clips are within the loop.
Which brings me back to the first hypothesis, but the problem might not be in how the loop is calculated, but in how the start and end of audio clips are calculated. This should be done in sample count, but it seems to me that it's done in time.
]
[Edited 3
After several tests, I'm almost certain the problem stems from the change in the Time/Sample measurement resolution.
Hypothesis:
Samples have a higher resolution, so the same time can fall on different samples in each loop calculation and at the start and end of a clip.
If the loop doesn't match the start and end, the loop calculation takes precedence and always falls on the same sample. However, if the start and end are within the loop, recalculating them can cause errors.
I don't know if fade in/out can also play a role.
Does this make any sense?
]
re. Timer setting?
assuming you're referring to the setting in View > Options... > MIDI > Playback > Queue timer (resolution)
the best would be set to "HR timer", always... but this mostly only deals with audio and MIDI sync in regard to external (to qtractor) clients or devices.
ALL internal processing (within qtractor premises that is), plugins and looping included, is frame/sample accurate; automation being the exception as it runs on a fixed 64frames resolution (or even less, if the period buffer-size is insanely shorter than that).
but this is all moot or of no consequence if and when the system is loaded or already hosed--there's always a physical limit when scheduling threads start falling short to their deadlines--there is always a limit to what any physical entity can do, no matter what you may call it "real-time" or else...
cheers
Thanks for clarifying the doubt
Your explanation makes sense. It is simply a lack of processing capacity on the part of the hardware. That's why it's cumulative.
I suppose it becomes more evident with clips within loops, and less so in clips intersected by the loop, simply because it does not have to calculate the beginning and end cuts of the clip.
Stop playback for a few seconds and resume syncing again.
As for random artifacts at the end and beginning of small loops, I have found that adding the minimum fade in/out type increasing decreasing eliminates them without the fade being perceptible.
Possibly they are different things.
Greetings
mute/unmute
My current experience is that selecting all audio tracks and mute/unmute them while playing fixes all strangenesses regarding sync – at least until the loop repeats.
I have the impression that mute/unmute applies some magic that puts everything in the correct order.
re. mute/unmute...
on audio tracks, mind you, it actually stops (mute) and resumes (unmute) the track-clip-playlist-threads, so you actually have a point, some at least ;)
cheers
So, how about adding the…
So, how about adding the mute/unmute audio function to the panic button?
If we notice anything strange, we can press the button and resynchronize.
Although the panic button is designed for MIDI, this is actually a panic situation.
There's something that…
There's something that bothers me about all this.
1. This didn't happen before. @bluebell, you only noticed it relatively recently. I hadn't created a real multitrack project in a while, and that's when I noticed the desync. (Before I was just playing with small test projects, percussion loops with a few chords, only MIDI. Or mastering single-track audio projects).
2. Qtractor hasn't changed the way it handles playlists.
3. It desyncs equally on Jack and Pipe... it's not the engine either.
4. Okay, our computers are old, but they didn't desync before... and they're still the same.
5. I think everything points to newer kernels... I'm mostly blaming someone... XD
You're going to laugh, I…
You're going to laugh, I just did a test on a partition I have with a generic kernel, and so far there has been no desynchronization with the conflicting session.
I can't guarantee it.... but @bluebell if you can, try it.
Maybe low latency kernels are starting to be counterproductive.
priorization
One of my thoughts was that the "setup"-task in Qtractor should be priorized. So your experience seems to point into the same direction.
Another approach could be restarting the track-clip-playlist-threads whenever playback is stopped or the playhead is manually repositioned. Restarting it when playback is started or the playhead is manually repositioned would probably work, too, but it could add an audible delay I am afraid that might be bad especially when Qtractor is synchronized to other hard- or software.
Kernels.
Interesting.
This is my observation for more than Qtractor. I use Linuxsampler all the time, and it was back in the kernel 3, 4, and 5 series that I got the best results for lesser hardware. Now I have two computers that are the most powerful i've owned, and i have to tweak LS compilation more precisely to get near the same performance.
What's the difference? (systemd?)
I think you're onto something here, and it's a useful clue for getting more performance, and reliability.
I just installed a generic 6…
I just installed a generic 6.8 kernel on Ubuntu Noble Studio.
I'm on PipeWire. So far, no desynchronization has occurred, and the cores don't seem to be overloaded (that was the difference I noticed before between generic and low latency).
It may be a little more prone to XRUMs, but I'm not sure yet; it's not significant.
When I've been running for a few days and make audio recordings, I'll let you know what I think.
Crazy hypotheses from someone who has no idea but is trying to understand everything... Low latency kernels work by not starting a task until another is finished.
If you work with audio and MIDI... and until the MIDI task is finished, the audio task doesn't start... desynchronization is guaranteed.
Add new comment