I made a recording of electronic drums into a MIDI track. Not that it would matter for this issue, but I then feed this into multiple buses using MIDI key-range plugin for splitting.
I then connected the buses back to the drumset for playback to review a recording. I selected a region and put it in a loop to continuously listen to it. All good, but after like 5 or 7 repetitions the tempo suddenly changed and it became about 20-30% slower.
Restarted Ardour and JACK, same. Later, I believe after a computer restart, it went back to the correct tempo - happy.
Next day, I opened the session and the tempo was again incorrect i.e. 20-30% slower. It did not happen after any changes, or during playback/looping, I just started the computer and then the session.
In both cases, I am 100% sure that I did not touch anything on the Ardour UI. In the first case I actually had the application out of focus. I then looked at the Undo option, the last action that can be undone is “Select loop from range”, also indicating that no action was taken after I instructed Ardour to loop over the range.
The tempo/beat on the Ardour still indicates the defaults i.e. 120.00 and 4/4.
First, how did this happen?
Second, how can I get this back to the original tempo?
What version of Ardour, and from ardour.org or from your linux distribution repository?
There have been quite a few changes to time and tempo handling in the most recent released version (7.5). Not to say definitively that any of the changes address what you saw, but definitely old versions were known to have some problems (mostly around tempo maps).
What version of Ardour, and from ardour.org or from your linux distribution repository?
I installed the Fedora Jam distribution, which provides v6.9.
I then upgrade to v7.5.0 using the Fedora package manager.
I created the session at 192kHz directly in v7.5.
I recorded and edited MIDI.
I have not changed the sample rate in any way in this session.
In qJackCtl (using jack 1.9) Driver is set to Alsa and MIDI driver to seq.
If relevant, under Misc/Other, ALSA sequencer support is enabled.
I did switch from JACK to ALSA and back on this session, trying to troubleshoot the other issue that I’m having with no playback sound at 192kHz, however I think that was after the first occurrence of this tempo issue.
It also sounds like running at a different sample rate than originally.
There’s a chance that PipeWire has issues with 192kHz. I started this session as just a test, and I don’t plan to use 192kHz a lot. But I did end up with a good recording that I don’t want to lose. Is there a way to export the MIDI tracks/buses and import them into another session of lower rate? I will then also be able to confirm whether I encounter this same issue or whether it’s specific to 192kHz.
Nothing to do with the distribution, I now use AVL-MXE that comes with Ardour 7.2 - I initially encountered this in Fedora JAM with Ardour 7.5.
Not sample rate specific, this project is on a different sample rate (96kHz) that otherwise works fine - I initially encountered this on 192kHz.
Nothing to do with PipeWire, AVL-MXE does not use it at all - I initially encountered this with PipeWire/Jack2.
Not specific to MIDI, this project only has audio tracks - I initially encountered with playing back MIDI recording.
No special configuration, just a bare-bones project where I recorded a couple of tracks. Playback just goes slow all of the sudden, and in the case of audio tracks a lot of distortion.
This does sound like playing back at a different sample rate than recorded. I’m 100% certain that in all cases there was no user input that would cause such change.
I’m running Ardour with JACK, both indicate the correct sample rate.
This happens in the middle of a working session and actually when not doing anything i.e. not recording or changing any settings (can’t change the sample rate in Ardour anyway).
Restart Ardour, restart JACK, restart the OS, repeat, nothing - the issue still occurs.
Doing nothing but restarting the laptop after a few hours - the issue is gone.
What could I look for to troubleshoot? Is there a way to validate the sample rate during playback with a tool or even Lua script?
I never had issues with Ardour 6 in a similar setup, could it be a bug in Ardour 7? The timing is interesting, if it indicates anything i.e. when it happens it sticks for some time and it survives OS restart. After a few hours is gone.
I thought it could also be related to the laptop’s CPU performance/power management, since I observed that the last time it happened I was running out of battery; not aware of a mechanism that would cause that, but you never. I charged up to 50% though and it was still occurring. Shut down, unplugged the battery, opened later after a few hours (i.e. still on 50%), back to normal.
On my system, I have to disable Pipewire and Pulse Audio to prevent this type of problem.
I use the ALSA drivers, or JACK2 ( QJackCTL)
Ubuntu 22.04 LTS
In the CLI, these commands. I dont know if they are the same for AVL linux.
Is it always the same audio interface? Perhaps it is a hardware problem with the sound interface.
I thought about that possibility, but then I used Ardour 6.9 with the same interface for a few months and I never had this issue. I will contact the manufacturer to see if they have anything to say, but Focusrite does not officially support Linux so I don’t expect much.
On my system, I have to disable Pipewire and Pulse Audio to prevent this type of problem.
Let me try that, AVL-MXE claims that Jack and PulseAudio are configured to co-exist peacefully, but you never know.
Also, I put the CPU into performance mode
The fans go crazy in performance mode, but I can do that for testing during editing to see if it eliminates the issue.
One more thing I forgot to mention, I had MIDI devices that were sending clock out signals. This caused a MIDI Jam that actually caused a lot of similar audio problems as well. I turned the external MIDI device, a MIDI workstation, send clock off. This also cleared up the audio issue. I don’t know if you have your MIDI devices hooked up when this happens.