Are there any raspberry pi alternatives particularly well-suited for running Ardour?

Been looking around at some beefier alternatives to Raspberry Pi but I really don’t have much of a background in CPU architecture, integrated chips (esp for DSP), etc. so I’m not really sure what I’m reading.

Do you, off the top of your head, know of any that might work well for Ardour? Cost is irrelevant so long as it’s cost-effective.

Asus Tinker Board, Compulab’s Fitlet2,… but unless you really need very small computer to hide somewhere or to carry it in your pocket or for wharever purpose where small form factor is crucial, it would be much more cost effective to buy some used laptop. Even the lowest end Intel based new laptops will run Ardour much better than any SBC. As far as cost goes, SBCs are sold as barebone computers so when you buy adequate SD card, power supply, keyboard, screen,… cost adds up quickly and you end up paying more than for some cheap laptop.

Well I’m talking about embedding Ardour in a device and mass producing. So the laptop thing doesn’t work.

Of the boards you mentioned, aside from having larger CPUs, is there anything about them that makes them better at Ardour or DSP? Is it possible for Ardour to leverage a DSP chip in some way or does it deal exclusively with CPUs?

Ardour itself does not do any DSP at all. It only has signal level meters and applies fader-gain, but that’s as far as it goes. However there is SSE and AVX asm language code to optimize this. This is used on CPUs that support those instructions.

Plugins that do DSP could use DSP-chips. For example some universal-audio plugins do that and those plugins work with Ardour on platforms they support.

Anyway, what issues do you have with running Ardour on the Pi?

The harder issue is making a RPi suitable for realtime (read: reliable) pro-audio use, in particular hardware I/O configuration (e.g. network and USB share the same bus and hardware IRQ). Maybe have a look at http://zynthian.org for some prior art.

As for alternatives: I’ve used some Kontron as well as some Advantech fanless single-board PCs. They’re not low priced, but still much cheaper than a proper sound-card.

1 Like

And on a system with a DSP chip, does this leveraging happen automatically at the operating system level?

While I could get very basic DSP processing for my guitar, the latency was huge and seemed to cause crashes with heavier loads (i.e. more plugins). I couldn’t keep Ardour open for very long under any circumstance, really.

The latency at least, is that something you’d expect? If you’re saying that Ardour (sans plugins and DSP) should work fine on a Raspberry Pi, I don’t really have evidence to contradict that.

Thanks for the further board suggestions. I’ll look into it.

Nope. Plugins have to be written to use a specific chip and also need to be given permission to access it.

Crashes are not cause by heavy load. Usually this would indicate unstable or substandard plugins (and yes, there are sadly a lot of them).

Yes. I didn’t manage to get default Raspian system with a USB card to work reliably, even at rather large buffersizes. And USB devices also have a rather long and unpredictable systemic latency.

However zynthian’s preempt_rt kernel and their custom soundcard does an an amazing job. Nominal latency is 2 * 128 / 48kHz and the custom soundcard’s systemic latency is small. Round-trip latency is well below the 10ms mark, and it can go for days without a dropout.

If you need ultra low-latency DSP, I suggest to use https://bela.io/ – that is however not a system where you could run Ardour on.

Well I suppose now you could try the raspberry pi 4 that just got announced and see if it works better for you for the record.

And for any small processor no matter the architecture, ARM or low power x86, if you are running linux you should tune it the way you would any linux system that you want to use for really low latency operation, namely use an RT patched kernel, use rtirq or similar to make sure the RT priority levels are set appropriately, and scrub through the system services with a fine toothed comb to pull out anything you don’t absolutely need to keep the OS footprint as lean as possible.

So after the Pi 3 b+, I attempted an Ardour/guitarix setup on an older laptop I have sitting around. Specs:

  • Ubuntu studio (low latency kernel)
  • Quad-core core i5-2430M @ 2.4 Ghz
  • 6 GB total ram (which seems weird, but that’s what top and free say)
  • No USB 3.0
  • Audiobox USB 96

The results were good. Latency was fine. System seemed stable.

Obviously these specs outstrip the Pi 4 B, but they are reasonably close… ~50% better? I’m looking forward to getting a new Pi and giving it a shot.

Just measured my 2 laptops and the Raspberry Pi 3 B+ with jack_iodelay. All @ 48000/256/2 through Audiobox 96 USB interface

Thinkpad carbon x1 i5-5300U CPU @ 2.30GHz, 8 GB ram
1326.281 frames 27.631 ms total roundtrip latency
extra loopback latency: 558 frames

Thinkpad e420s i5-2430M CPU @ 2.4GHz, 6 GB ram
1274.828 frames 26.559 ms total roundtrip latency
extra loopback latency: 506 frames

Raspberry Pi 3 B+ (stock raspian)
4589.929 frames 95.624 ms total roundtrip latency
extra loopback latency: 1517 frames

Raspberry Pi 4 B (stock raspian)
1256.920 frames 26.186 ms total roundtrip latency
extra loopback latency: 488 frames

Looks like the Raspberry Pi 3 B+ is a little more than 3x worse than the laptops. I’ll post another measurement when I get the Pi 4.

Edit: Just discovered that the speakers I was using (integrated into a TV set) were adding significant latency. Plugged in one of these laptops (which I tested earlier to be fine) and could definitely hear lag. Moved the patch cable to an external amp and it was fine. I guess the TV set has some internal analog to digial conversion with significant lag. This means I need to retest the Pi 3 B+.

Edit 2: The TV was not involved in the jack_delay measurements above. By “retest the Pi” I mean my previous audible test was through the TV and I need to retry that through a normal set of speakers.

Edit 3: Should be noted the laptops were running on a lowlatency kernel. The raspberry pi was running on “stock” raspian.

Edit 4: In a shock twist, running the raspberry pi (and Audiobox A96) through a real speaker (instead of the laggy TV speakers) the latency was acceptable. I think I could detect it very slightly but that could be in my head. It was extremely minor, if any. Stability of Jack/Ardour/GuitarixLV2 was bad at 128/2/48000, though. I have high hopes for the Pi 4.

Edit 5: Added results for Raspberry pi 4 B.

Modern lcd TV’s take their time with conversion yes but often a lot of the delay comes from the processing they do for video. This is a major issue from live usage for instance and we often look for specific models known to be low latency, but if all else fails look for a game mode on the TV to minimize it as much as possible or at the very least shut off as much processing as possible.

And yes your laptop should be able to get better latency numbers than you mentioned at least, which likely means that the rpi can also get better numbers most likely. Those numbers wouldn’t be acceptable for live usage from either the laptop or rpi.