Forums
I think there's an old bug hiding in the code which leads to single audio clips played too early (about one beat) when
- having a session that makes some load due to many plugins
- having many instances of an audio clip on an audio track, each with separate offset and length, the situation that happens when you align vocals to the beat or transpose or stretch some parts
- repositioning the playhead and press play immediately
It can be avoided when I wait a second after repositioning the playhead until I press play. At least I could never reproduce it when I wait a second after positioning the playhead.
So I think there is some asynchronous processing after repositioning the playhead that prepares the audio clips to be played at the proper time. And I think it could be fixed by delaying play until this setup has finished.
I'd like to examine the code but I cannot find the place where the playhead is repositioned.
File attachments
re. Need help examining an old problem...
yes probably... but first check if the problem is happening the same at loop turnarounds (please try and set the loop-start point at one of the known (manual) play-head repositioning)...
seeya
Not in loops
I never encountered this effect inside a loop. I guess the audio clips are setup once before playback starts.
It might be possible that it occurs in a loop, too, when I press play immediately after repositioning the playhead. Then it should happen in every loop pass. But I couldn't reproduce it so far.
There is another problem with loops: a small drift in time when loops are inside he bounds of an audio clip. Then – depending on the length, offset and whatever else – the audio file drifts after lots of loop passes, maybe during a rounding error. But this should be a completely different issue.
.re There is another problem with loops
Yes, and that small offset at the beginning causes random artifacts when looping is activated, since the waveform doesn't start at 0 when it skips forward.
I never thought it was a big deal because I only use loops as a reference. But it's annoying. If it can be fixed, it would be welcome, although as I said, it's not a big deal to me.
I suppose if someone wants to use loops to send audio to other applications, then it's a critical issue.
I don't know if it would be worth opening a separate thread for this topic.
Would be cool if those 2 problems could be solved
1.) The slow drift of audio files in loops is not nice but won't ruin a mix
2.) The – let's call it – async setup of audio files forced me to redo mixes (realtime recording because bouncing doesn't work with complicated routings). Playing a song from the beginning should be a fire-and-forget thing (except when xruns occur) but unfortunately it isn't.
I am aware that 2.) isn't easy to be reproduced. It depends on a given realtime load and maybe lots of clips of the same audio file with different lenghts and offsets. I am still trying to create a test session where it happens but I failed so far.
Maybe another hint for the loop drift [EDIT][EDIT2][EDIT3]
I noticed that something that might be related to the loop drift occurs when
although all audio clips are within the loop.
The first run and some loop iterations are fine but on others audio of this clip is garbled or silenced.
See screencast and sample session.
My first guess is that it's not rubberband itself but the time it needs for processing.
EDIT: I am afraid the sample session won't be of any help because the issue happens on my slow core i5 only, not on my core i7. This will make it hard to fix but it must have something to do with some async stuff that's not finished in time.
EDIT2: I could reproduce a few issues when setting the core i7's governor to powersave.
Maybe the rubberband processing is done again and again for each loop iteration? Is it then the same as positioning the playhead and press "play" immediately, so it's finally the same root cause as other issues with audio clips that I have from time to time: some async processing for the audio clip without waiting for its end?
That would have some nasty implications since the audio clips' setup must be done only once and not for each loop iteration else each loop iteration might pause for a moment.
EDIT3: It's noticable that the first pass is never a problem and that sometimes there is a pattern which pass works and wich not.
Add new comment