Tribulations with Raspberry Pi 3 B+. Need advice

Long story short, I was able to:

  1. Get a Pi 3 B+ running.
  2. Get it to recognize my Audiobox A96 (was plug and play).
  3. Get Jack running through the Audiobox (but only from the command-line) with jack -d alsa -d A96 -r 48000 -p 128 -n 3. Qjackctl will not run due to a bug in QT or something.
  4. Get Ardour running, start a new session and add a couple of Audio tracks.
  5. Map the inputs from the 2-port Audiobox to the 2 tracks in the session. I can see meter activity in the two tracks.
  6. Hear output through my speakers, but…
  7. Load gxAmplifier-x into the 2nd track to color the guitar sound. DSP ranges from 20% to 40% depending on the settings when starting Jack. Closer to 40% with the settings above.

The problem is the guitar sound I hear in the speakers is plain, uncolored. As if the master output from Ardour is not going to the Audiobox, though the “master out” green dots seem to be linked to the right hardware output. When I try to adjust output connections (through Ardour, remember qjackctl doesn’t work), either Ardour or Jack (or both) freezes on me. I have to keep killing processes just to try again. And yes, I have the mix knob on the Audiobox set correctly.

Should I start Jack with a different command or something? Why can’t I hear the effect of the amplifier sim on my signal? And why are Jack/Ardour so prone to freezing or crashing (which I experience on my laptop several times per day)?

I’d be surprised if a USB device works OOTB wit 128 fpp on an ARM CPU. Even on a modern Intel system, one usually needs a preempt-rt kernel for anything lower than 256 * 2 @ 48k.

As for the actual issue at hand, I guess you’ll hear yourself via hardware, zero-latency montoring: Do you also hear the guitar when Ardour isn’t running?

Also is there a specific reason why you use JACK and not Ardour’s built-in ALSA backend?

This is not normal behavior.

But since you mention guitarix: There are a couple recent reports that guitarix GUIs cause crashes and deadlocks when used with Ardour. Apparently even distro builds are now prone to this. A solution is to use guitarix from git (no more gtk GUI) or to not open the gx UIs.

That’s just a guess though, to be certain, a backtrace would be needed: https://ardour.org/debugging_ardour

I’d be surprised if a USB device works OOTB wit 128 fpp on an ARM CPU. Even on a modern Intel system, one usually needs a preempt-rt kernel for anything lower than 256 * 2 @ 48k.

Is this a function of the power or design of the cpu? I.e. maybe raspberry pi 4 or 5 might do it in the future? Or is ARM incapable for some reason?

As for the actual issue at hand, I guess you’ll hear yourself via hardware, zero-latency montoring: Do you also hear the guitar when Ardour isn’t running?

Yes. That’s what is happening.

Also is there a specific reason why you use JACK and not Ardour’s built-in ALSA backend?

I sort of need to be able to watch/hear YT videos while making cover sessions. But I guess I could use my phone. And for a Thingamagig computer designed only for recitation, built-in ALSA could be fine.

This is not normal behavior. reply to (And why are Jack/Ardour so prone to freezing or crashing (which I experience on my laptop several times per day)?) But since you mention guitarix: There are a couple recent reports that guitarix GUIs cause crashes and deadlocks when used with Ardour. Apparently even distro builds are now prone to this. A solution is to use guitarix from git (no more gtk GUI) or to not open the gx UIs.

I also suspect guitarix to be the problem. But (and I probably asked this before) why should a plugin be able to crash Ardour (or Jack). Shouldn’t Ardour be able to rope that off like Chrome or Firefox does for addons?

That’s just a guess though, to be certain, a backtrace would be needed: https://ardour.org/debugging_ardour

I believe I’ve done this before and found gx_livelooper to be the culprit in many cases. I’ve emailed with brummer some to get attention on these issues, some of which he has fixed, but it sounds like getting them into Ubuntu repos is a pain and not even guaranteed. I don’t want to use any external repos because I want the system to be extremely easy to configure for noobs.

It really is maddening, though: In any given 1-3 hour session at the computer, Ardour crashes a dozen times and QLC+ crashes a handful of times. What’s crazy is that when I open Ardour and load a session and it craps out, you’d expect that to happen every time. But if you open the same session 2, 3 or 4 times, it’ll eventually load. Seems like it should be consistent about crashing, at least.

In any case, thanks for the response. Sorry if I sound frustrated.

Sandboxing plugins adds unreasonable overhead. In short: it does not scale. CPU context switches add DSP load. http://lists.ardour.org/pipermail/ardour-users-ardour.org/2015-August/027373.html is still valid, the numbers have not changed significantly since.

Even worse, even if there was some crash protection, there’d be an audible artifact when a plugin dies (and is restarted). That is a big no-go when performing live and also unacceptable when in the studio.
Plugins that can cause issues should either be fixed or not be used. Sandboxing is not a valid solution.

Anyway, context-switches are also related to why USB and low latency is at odds. The default kernel cannot reliably handle USB IRQs, in particular if it is busy doing other IRQ work (graphics or network). It doesn’t help that the USB stack is rather complex. Still a realtime kernel which is configured to preempt IRQ handlers will help a lot. This is not directly CPU architecture dependent.

I guess your system live-locks when you start jack with realtime permissions at 128fpp, and you may also run into memory limits on a RPI 3.

That would be consistent with some memory corruption issue: ie. writes some data to some random memory-location and the effect may or may not be immediately noticeable. It can lead to crashes or odd behavior anytime later.

ARM CPUs are also peculiar with memory alignment, I’d not be surprised if some plugins get this wrong.

I’m sorry for the abysmal experience you have. For many others it runs for day at a time.

One day I’ll record my whole desktop while working so you can see how things are crashing. Could be educational.

Curious, what do you expect anyone to learn from this exercise?

I would rather like see backtraces that can help fix issues and/or indicate which plugins or workflows to avoid. That’d be helpful.

The timing of the crashes, what I’m doing at the time of each crash, the frequency of the crashes, and which of the programs (Ardour, QLC+, a2jmidid, jack) is crashing is surely helpful to observe.

Not really helpful at all. What is helpful are recipes reported in the context of bug reports. It is true that in the recent past (read: the last year or so) we have not been paying much attention to them, but this is a much, much better avenue towards things being fixed (if indeed it is possible for them to be fixed inside Ardour).

We are far from the only DAW developers who on some level absolutely hate plugins. I’ve had conversations with the lead developers of at least a couple of major proprietary DAWs who report more or less the same thing: that plugins are just about the biggest headache they face, and they generally wish it was possible to put the plugin genie back in the bottle (sadly, it is not).

@Paul: Its not helpful to characterise plug-ins as some evil which is responsible for any problems with your software. Over the years I have personally had to implement numerous workarounds in my plug-ins for ardour specific bugs, or failures to implement plug-in formats correctly at one time or another. The problem is not only plug-ins, or only host applications, and it would be foolish to lay the blame solely at either. Plug-ins make ardour more flexible (and more attractive) for your users, the trade-off is that sometimes bad plug-ins cause crashes, just like some bad applications cause crashes all on their own.

Mike - it wasn’t me who said “Fuck plugins. Fuck them all.” I am also sure that it wasn’t the intent of the lead developer of <super-hugely-successful-proprietary-DAW> who did say that to imply that the problem is with plugins individually.

We “hate” them not on a case by case basis, but because loading arbitrary 3rd-party object code into our programs is a nightmare. It’s a nightmare for us, it’s a nightmare for just about every DAW development team out there.

That doesn’t mean that we don’t recognize the power that the concept brings for users - it’s huge and it’s valuable. But it also recognizes the fundamental absurdity of “sure, the user can load whatever 3rd-party stuff they want into our host, and we just have to deal with it”. It also recognizes the equivalent absurdity for plugin developers of “well, Logic does it like this, Live does it like that, DP does something sort of inbetween and Reaper has developer an extension to work around this problem”.

You will have noticed, no doubt, that most proprietary and open source DAWs increasingly come with basic “plugins” (read “DSP modules”) to try to reduce the need for beginners to use plugins at all.

Small update: I was able to get “hello world” working (i.e. a guitar into Audiobox, signal into plugin-modified audio track, colored sound coming out of the speakers). I was able to do this through Ardour’s built-in ALSA as well as JACK. Unfortunately, it was very unstable (both ways crashed out pretty quickly), there was a lot of popping and the latency was unacceptable for the application. I know I got 48000/512/2 working… maybe 256 (can’t remember). In any case, it dosen’t seem like RPi has the horsepower necessary for real use.

Side question: From what I can tell, RPi has no audio input of its own, correct?

If you must use a RPi for audio, get one of these https://www.hifiberry.com/products/dacplus/
or one of these https://blokas.io/pisound
Don’t bother with Ardour, its too much of a resource hog for the Pi, use Reaper for ARM or Tracktion / Waveform instead and don’t use JACK. By the time you’ve amassed all the necessary bits and pieces to make it work, you may as well have got a second-hand Dell or whatever off ebay for less money and vastly more processing power. I was able to run a 24 track session on a RPi3 (with EQ and dynamics plug-ins in each channel) this way - which is kind of interesting because its possible, but not really much use

Why? It does work very well and reliably as HDR, even a couple of basic effect units are fine, and yes, that is without JACK on a RPI3b (no plus).

But guitarix is kinda heavy, compare to the MOD, it’s very easy to cap DSP load even with a single instance of it.

RPi is a pretty poor architecture for low latency applications, the network controller is connected through the USB controller, so if you have a USB audio interface there can be a conflict if you need audio and network at the same time. If you do not need network try setting your Ethernet interface down to see if that improves the audio performance.

It was more Ardour’s GUI that was the issue for me. It can run the DSP, but any interaction with the application seemed to get bogged down quite quickly. Perhaps this is more a GTK thing, or maybe it can be helped using a different compositor etc - or maybe there are new ways to optimise Ardour’s build I was not aware of - but I found Tracktion / Waveform on the same hardware to be much snappier (e.g. I wouldn’t have known it was only running on a Pi)

If Jalv or Carla-single would have Non-session-manager (NSM) support, you could run LV2 plugins as JACK standalone application and use them with Ardour within a NSM session (Ardour has NSM support as well).

Of course this is already possible using Carla, but Jalv or Carla-single might be a cleaner / more minimal solution.

Afaik NSM support for Carla-single is in the roadmap.