I was doing some recording in Ardour yesterday evening and encountered an odd timing problem. I was using Ardour3 and Hydrogen sync’d via Jack and then using Ardour’s MIDI clock output to sync a couple external devices (DSI Evolver and AndrenaLinn 3)
I had the BMP on the display on the Evolver and noticed that over time, it gradually increased or decreased by ~10BMP and then would suddenly reset itself back. At the same time, recordings made in to and playing back from Ardour were pitching up and down in resonse to this which obviously made recording impossible.
I’m running with a Mackie Onyx 1640i as the audio interface and using a BCF2000 for the MIDI sync. I’ve got a pretty low-latency setup (~11msec) but I didn’t see more than a handful of xruns over the whole session of a couple of hours and my PC (8 core, 8GB RAM) should be mroe than powerful enough to handle it. My only though is that I’m using quite a heavy GUI so I could change to something more lightweight (fluxbox) but I wondered if anyone has encountered anything similar?
Just to update on this, I moved to the Fluxbox desktop last night and still encountered the problem though it felt slightly reduced. One thing I noticed was that of the two bufferes indicated in the status bar of the Editor Window, the playback buffer oftern dropped down to ~50% while the capture one remained at ~99% for the duration. The DSP however never got about ~15% which makes me think the system load is probably not the issue.
I cannot reproduce. Midi clock works fine here (ardour 3.5-4286, jack2 v1.9.11, a2jmidid -e), as well as Ardour’s build-in ALSA backend and I remember it also worked with earlier versions of Ardour3 just fine.
The best guess guess is that the the issue happens between JACK and the soundcard’s I/O, but ~10 BPM jitter is a lot. That’s certainly odd.
There will certainly be drift due to any xrun but since you only had a handful in a couple of hours that’s can’t be it.
Could you try to track this down? Basically follow the signal… until you find the point where you see it goes wrong (jitter, lost data etc…)
First step is to make sure the data sent by ardour is correct. I assume you are familiar with commandline tools. The easiest way to do that is to run
jack_midi_dump -r # this tool comes with jack, -r: relative timestamps
and then jack_connect “ardour:MIDI Clock out” midi-monitor:input
There should be ‘f8’ messages at regular intervals. specifically every (SAMPLERATE * 60/24 / BPM) audio-samples.
e.g with 48KSPS and 120BPM jack_midi_dump -r should print a series of “+1000 f8” messages.
If that is fine. Use a loopback cable. Ardour -> soundcard MIDI out -> Midi-cable loopback -> soundcard MIDI in -> jack_midi_dump
and check if the signal is still without jitter every N samples.
Some more convenient tools are available from https://github.com/x42/jack_midi_clock : jack_midi_clock (which is not unlike ardour’s MidiClock generator) and jack_mclkc_dump (which dumps incoming midi-clock and follows it using a PLL, displaying jitter and filtered BPM).
In any case it might be easier to discuss this interactively on IRC. (Ardour > Help > Chat)
I’ve fiddled with the settings a little and checked there’s nothing draining the CPU and it’s slightly better but still happening. Basically, when I start up Jack, Ardour and Hydrogen, they run at the specified tempo and then slowly drift either slower of faster in pretty much a linear way with time until the tempo is about 10 beats slower/faster and then there’s an XRUN and it skips back to normal.
When the tempo has drift, already recorder tracks in Ardour play slower/faster in time with the drifted tempo, pitching up and down, while tracks being recorded are recorded faster/slower so that when played back at the correct tempo they play slower/faster and pitch accordingly. It’s driving me crazy.
I’ve got my Jack set to Frames/128, Sample Rate 44.1k, Periods/4 with Realtime set giving a latency of 11.6ms which seems to run without only the odd XRUM here and there, the Ardour Capture and Playback buffers run at about 50-70% during recording and playback and I’m only using about 15% of the DSP capacity even when running about 20 plugins. The main change I made today was to mount all my partitions with the noatime option. I’m all out of ideas, any furtherr suggestions?
I tried the commandline tools and didn’t see anything out of the ordinary - is there a tool that just reads MIDI clock and displays the BPM? I’m pretty sure the reading on my Evolver is accurate as to what Ardour is putting out. I’ve got the MIDI clock feed coming back into the system but nothing obvious to read it with.
Ardour is set as the clock master (I think) with Hydrogen and the external devices slaved - Ardour 2 used to have an obvious Master button but that seems to have gone in version 3?
4 periods/128 frames was just a random choice as I’m not sure of the differences but I’ll try 2/256 this evening.
The master button has not gone, but is unrelated to MIDI clock. The “time master” button is related to JACK and JACK alone. The relationship with MIDI clock is defined by two separate options, one to send MIDI clock (under the MIDI tab of Preferences) and one that selects MIDI clock as the time sync source. Whether to use the selected time sync source is chosen directly in the transport bar viewable in the editor window.
After some further experiments tonight, I think the problem might be Jack related rather than a sync problem. QJackCtl is showing a Maximum Scheduling Delay of about 750ms which is huge and probably explains the drift issues I’ve been having. the still system doesn’t seem to be under any load but I’m going to increase the latency and see if that fixes the issue.
The only other thing I’ve got running is PulseAudio which might be causing a problem.
OK, so had a good play last night. I’ve disabled PulseAudio and while it seems to have improved timing stability (though this is quite subjective - it just feels like it’s taking longer to drift) but it’s still not stable. The only thing I’ve not tried is pushing the latency up really high which I will do tomorrow but if anyone has any other suggestions, I’m all ears.
It has crossed my mind that it’s a hardware problem with the desk - does anyone have experience with a Mackie Onyx 1640i?
How do you configure it in Jack and does it seem to have have a stable sample rate?
I’ve just been doing some messing about with Hydrogen without using Ardour and I’m still experiencing the same problem - the sample playback rate of the system gradually increases over time so that sound playing back through the desk gradually gets fast and fast until there is xrun which is always about 746ms in length and then the playback rate returns to normal before drifting off again. It’s like something between the desk and the audio system is not syncing properly and every so often it corrects itself.
This sounds like you have a clock sync error in your setup. Can you describe what exactly your complete Audio Setup is (All equipment involved and what is connected to where, and how, such as analog or digital in particular)?
I’m using a Mackie Onyx 1640i as the audio interface, connect by firewire and I also have to Behringer BCF2000 unit connected by USB with one being used as a MIDI interface to sync MIDI clock with external devices. I’m using four channels in the desk for guitar (stereo from a few pedals, channels 1+2) a bass with a phantom powered DI box (channel 4) and a phantom powered mic (channel 6)
In the computer, I’m using qjackctl configured as follows:
Realtime on
Priority (default)
Frames/periood 256
Sample rate 44,100
periods/buffer 2
Port Maximum 256
Timeout 5000
Name default
Driver firewire
Interface default
Audio Duplex
Channels/Latency I/O All default
Start Delay 2 secs
I’m then running a2jmidi to bridge ALSA and Jack MIDI and running Hydrogen and Ardour 3 sync’d via Jack with the Ardour’s MIDI clock output sent to sync external devices via one of the BCF2000s.
I have PAM configured as follows: @audio - rtprio 99 @audio - memlock unlimited @audio - nice -19
It is important to be clear that MIDI clock “sync” has absolutely nothing to do with digital clock sync at all. MIDI clock sync is just a beat clock that describes current tempo and position in terms of musical time. It has nothing at all to do with ensuring that digital clocks remain synchronized.
Ok lets do some troubleshooting, as I see nothing there that should cause this. Just for grins and giggles, since you said the audio audibly speeds up or slows down, have you tried just playback through the Onyx, with nothing else connected to the computer at all? Does the audio still audibly change in pitch?