Ardour on Raspberry Pi 4 Model B first impressions and test results

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.

Setup:

  • 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?

1 Like

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.

2 Likes

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).

1 Like

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.

       Seablade

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.

Hello there,

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…

https://www.glassroof.nl/2019/08/19/running-ardour-on-a-raspberry-pi-4/

I will gladly share more details if anyone needs.

1 Like

Nice setup! Now you can almost build the whole DAW directly into the soundcard :slight_smile:

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.

   Seablade

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.

NAMA makes a pretty good text based DAW out of ecasound. https://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html
despite the dates on some of the pages, there is still development on it. And some music recorded using it: http://juliencoder.de/nama/