Received my Pi 4 B in the mail and got around to testing ardour today. Here is what I found:
processor : 3
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 108.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Hardware : BCM2835
Revision : b03111
Serial : redacted
- Using the jack-dev package causes Jack to fail to start. You have to use libjack-jackd2-dev. (If jack-dev is related to the “jack” CD ripping package, I’m very embarassed right now.)
- Good news: qjackctl works again. There was a Qt bug on Pi 3 B+ which forced command-line jack interaction only. Whew.
- I can’t get Ardour-5.12 sources to compile so I’m using the stock “ardour” package from the raspian repos. (See Build fails on Raspberry Pi 4 Model B stock raspian)
- My Audiobox USB 96 is recognized out of the box by the OS. (Pi 4 B still has no mic input, just like 3 B+)
- Jack starts up normally with realtime=true and 48000/256/2 (and obv using the Audiobox)
- Ardour starts normally using the jack backend. I couldn’t get the built-in ALSA to work, but also didn’t try very hard. It might have had something to do with my Audiobox’s finicky cable dropping the connection. Not sure.
- In Ardour with 2 audio tracks and 3 LV2 plugins (a-Compressor, gxTubeScreamer and gxAmplifier-x) my guitar’s input signal sounded fine. Couldn’t discern any latency issues. Only occasional errors of the type “JackEngine::XRun: client = jack_delay was not finished, state = Triggered, JackAudioDriver::ProcessGraphAsyncMaster: Process error, 11:13:44.233 XRUN callback (1).” (Turning off jack realtime created many, many more of these error messages.)
- Ardour reported ~30% DSP use under the scenario described in the previous bullet.
- For one attempt (of the previous scenario), the resulting signal was very staticky – lots of poppings – but that went away. Not sure what changed or why that was happening.
1256.920 frames 26.186 ms total roundtrip latency
extra loopback latency: 488 frames
These results are waaay better than the RPi 3 Model B+ and are now in line with my core i5 laptop. (See https://discourse.ardour.org/t/are-there-any-raspberry-pi-alternatives-particularly-well-suited-for-running-ardour/101230/12.)
Let me know if you have any questions. Seems great so far. Just need to be able to compile the sources so I get headless Ardour running.
Compiling on devices like this is hell. It’s much less of a headache to build stuff on a desktop using binfmt.d + qemu-( aarch64 | arm )
Thanks Reuben. Could you be a little more specific about how I accomplish this? The only thing I know about building Ardour is “waf configure” and “waf”. How does “binfmt.d + qemu-( aarch64 | arm )” come into play?
It’s not a build system, binfmt.d allows you to run software built for another architecture or os platform on linux. So you can mount a raspberry pie SD card somewhere on a x86_64 desktop/laptop and then use systemd-nspawn to open a new shell inside that mount point. You’re running a raspberry pi userspace at that point on an x86_64 computer. Compiling stuff at that point is waaaay faster than running natively on the actual raspberry pi, but not nearly as brittle and prone to breakage as a cross compiler. When you are done compiling, exit the userspace, unmount the sd card, and reboot the raspberry pi.
You need qemu installed. Distros can carve qemu up differently, but you basically need the static user package. Make sure the binfmt entries are set in /etc/binfmt.d/ (again, slightly different per distro) And then you enter the environment using "systemd-nspawn -D " You may need to add an argument to set the uid for the namespace if you are not doing this as root.
Here is some more information about my experience with RPi 4 B.
- raspberry pi 4 B (2GB ram) cpu-overclocked to 1750 mHz
- hifiberry DAC+ ADC audio input/output
- stock raspbian kernel 4.19
- ardour 6 (armhf) as provided in binary by x42
- one guitar audio track
- a handful (~3) of guitar lv2 plugins
- between 2-4 MIDI tracks with a-Fluidsynth for bass/drums.
- jack backend at 48000/512/2, 21.3 msec
With this setup, I avoid almost all xruns/dropouts and pops, but it’s teetering on the edge. Adding more plugins, having a browser open, messing with the ardour GUI, or stepping down to 256 frames/period all produce xruns/dropouts.
I also get heat warnings when playing back a track. I am not using a case nor fan, but do have heat sinks on the pi components. I believe the DAC+ ADC sitting on top restricts airflow, so that is likely a factor.
Any thoughts/insights would be appreciated. One question, would a RT kernel help with xruns? How much of a benefit could I expect?
Perhaps. The main benefit of that is that you can prioritize kernel-drivers/IRQ.
If the bottleneck is soundcard I/O or network or graphics, then yes it can help. If the bottleneck is plugins, and the CPU is the bottleneck, then improved reliability won’t help.
How can I nail down (beyond doubt) which is causing my xruns?
You usually can’t. There are various tools to investigate different paths.
I’d probably start to investigate kernel scheduling first:
cyclictest -m -S -d0 -p80 – the
Max number at the end should be small < 50 [usec] is reasonable on a modern Intel.
Check Ardour’s Window > Plugin DSP Load; and also check with
htop if the CPU is maxed out.
There’s https://github.com/raboof/realtimeconfigquickscan but take that with a huge grain of salt (in particular the reports about RTC clock and 000Hz timers, HPET are only needed for ancient MIDI applications and it may be counterproductive to increase those).
latencytop may be helpful, also some other tools from the rt-tests (https://rt.wiki.kernel.org) suite, but it’s not trivial to set that up
I just checked on the two Rpi-3b+ that I have here
default raspian, based on debian 10.0
$ uname -a
Linux rpi 4.19.57-v7+ #1244 SMP Thu Jul 4 18:45:25 BST 2019 armv7l GNU/Linux
$ cyclictest -m -S -d0 -p80
T: 0 ( 1145) P:80 I:1000 C: 132592 Min: 8 Act: 17 Avg: 18 Max: 311
T: 1 ( 1146) P:80 I:1000 C: 132564 Min: 8 Act: 17 Avg: 17 Max: 1435
T: 2 ( 1147) P:80 I:1000 C: 132545 Min: 7 Act: 13 Avg: 15 Max: 214
T: 3 ( 1148) P:80 I:1000 C: 132519 Min: 9 Act: 17 Avg: 16 Max: 1361
This shows that worst case it can take 1.435 msec for a context switch with default raspian.
In case you use 256/48kHz ~= 5.33 ms. JACK needs to wake up periodically at that interval.
However 1.43 ms alone can be spent to wake the application, and then only 3.9 ms remain to read, process and play audio/midi. So you have a 26% DSP base-load.
And zynthian.org optimized system:
# uname -a
Linux zynthian 4.14.29-v7+ #1101 SMP Thu Mar 22 17:27:30 GMT 2018 armv7l GNU/Linux
$ cyclictest -m -S -d0 -p80
T: 0 (20122) P:80 I:1000 C: 145734 Min: 5 Act: 20 Avg: 7 Max: 84
T: 1 (20123) P:80 I:1000 C: 145730 Min: 5 Act: 9 Avg: 6 Max: 79
T: 2 (20124) P:80 I:1000 C: 145719 Min: 4 Act: 5 Avg: 6 Max: 62
T: 3 (20125) P:80 I:1000 C: 145709 Min: 5 Act: 13 Avg: 7 Max: 50
worst-case is only 84usec. ~ 1.6% DSP load at 256/48kHz.
zynthian does use a hifiberry and runs jackd at 256/44.1k reliably (based on debian 8.0).
Thanks for this. I’m not sure I grok it entirely, but it sounds like there is a lot of improvement to be had from stock raspbian. This, too, can come later, thankfully.
Hmm learning about all sorts of fun projects, Zynthian looks very interesting. Gonna wait till a kit based on the RPiv4 is out I think, but dang that looks interesting.
Update: I compiled and installed raspbian with kernel preemption turned on. Now I can do 256/2/48000 with minimal (zero?) popping. Some xruns still appear in the jack messages log, but I don’t hear them.
Easy instructions here: https://www.raspberrypi.org/documentation/linux/kernel/building.md
When configuring the kernel, I only made ONE change, which was to set the flag for kernel preemption (can’t remember which menu… the label says something about desktop preemption). Other changes may help, but preemption definitely does.
Note that setting this flag kicks you out of 1929x1440 and down to 1080p. Not sure if you can work around that, but I don’t need to for my purposes, and it makes sense to downgrade for performance reasons.
$ uname -a
Linux raspberrypi 4.19.65-v7l+ #1 SMP PREEMPT Wed Aug 14 22:41:13 EDT 2019 armv7l GNU/Linux
You might consider creating a dedicated cgroup slice for the jack process to isolate it’s resource allocations from the rest of the system. That gives it a more dedicated slice of resources with less interruptions since it no longer has to compete with other processes for priority within it’s slice.
I have successfully built ardour on Raspberry PI 4 4G (Raspbian Buster) and got it running without any major issue. I still wonder if there is any valid use case for this though…
I will gladly share more details if anyone needs.
Nice setup! Now you can almost build the whole DAW directly into the soundcard
I’m curios: how long did it take to compile Ardour on the Pi itself? Is there a reason why you didn’t use Ardour from debian/buster?
As for ecasound to record, do you have any scripts to do that? Tag the takes, bump filenames, etc and import to Ardour? I found that using Ardour + OSC remote control is a lot more convenient. I think that Ardour+PIs main use-case is actually a HDR. With a small screen you could show the meter-bridge window, too.
PS. On the screenshot I saw that you’re using jackd’s “raw” MIDI driver. The timing and performance of these options is unacceptable. I suggest to use a2jmidid (see also http://manual.ardour.org/setting-up-your-system/setting-up-midi/midi-on-linux/) or better yet: use Ardour’s built-in ALSA backend instead of JACK.
Hell I would almost run it just for the meterbridge capability on some consoles if I could tie it into Dante (Not currently easy to do on Linux even if it may be possible). That meterbridge window is very nice, evne in live mixing.
I think it took around 2 hours to build once I got all the dependencies right. I have been stuck with old debian-provided ardour versions before, although it looks now much up-to-date.
Sorry, I have no experience with ecasound, but will test this soon…
I use JACK to synchronize Ardour and Hydrogen, but in this case I could use ALSA. Thanks for the tip on the raw MIDI driver. I will check on my main computer if this is also being used.
Is there a performance gain by ditching JACK for the built-in ALSA?
I know that in my previous iterations of my project, I needed JACK for routing MIDI notes to QLC+, but that’s gone now. I’m trying to remember if there’s any other reason I need JACK.
apt-get build-dep ardour5 should get all of them in one go.
Oh, nevermind then. Since you mentioned it on your website I thought you might already have some tools.
Yes, but it is negligible at all but very small buffersizes. It’s hard to quantify, mainly since JACK’s DSP load calculation uses a very weird averaging mechanism (Ardour’ ALSA backend reports worst-case by default).
Ardour/ALSA is pretty identical to JACK/ALSA, without the inter-application routing that JACK offers.
Apart from setup simplicity, the main use-case for Ardour/ALSA is MIDI timing as well as systemic MIDI latency calibration. jackd does not provide for this.