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

Getting Stuff Done Hints and Tricks
#15

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.

#16

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
#17

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.

#18

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.

#19

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.

#20

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.

#21

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/

#22

This is great, I’m glad performance is good, would if buffer is higher o assume it should handle a decent multi track mixing session with plugins fx etc

#23

Wanted to add a bit more feedback here. Having no issues running Ardour (lua only) w/ ALSA backend at 48000/256/2 on Pi 4 B 2GB with a Behringer UM2 USB audio device. My test sessions are multiple midi-based tracks running a-fluidsynth plugin + one audio track with multiple lv2 plugins coloring a guitar signal.

The only kernel optimization I did was to add PREEMPT. (I’m also using raspian with the desktop running which isn’t required for my ardour-lua purposes.)

pi@raspberrypi:~/aws-iot-device-sdk-js/examples $ uname -a
Linux raspberrypi 4.19.76-v7l+ #1 SMP PREEMPT Mon Oct 7 16:48:38 EDT 2019 armv7l GNU/Linux

Using a Flirc passive cooling case, my core temp is around 44C whereas the core temp of my other pi (4GB) with a hifiberry HAT on top (no passive cooling) is above 60C at rest.

During playback, I hear no pops, skips, or lags. Seems solid.

2 Likes
#24

That is good to know. I think the 4 may have crossed that threshold of being useful for more general purposes, and even some more specific ones like this. I am curious to see what can be done with it, and am hoping to order some here before to long, but gotta get my house sold first.

    Seablade
#25

How many Pi’s do you want to purchase? :crazy_face:

1 Like
#26

You are telling me I can’t build my house with walls of raspberry pis?

Seablade
#27

just curious… what do you get when you type this on your rpi4,
grep '' /proc/sys/kernel/sched_*

I recently tweaked my sched cfs params to match the same as AVLLinux and Ubuntustudio, and that helped reduce my x-runs… albeit I am using x86-64 on an RT kernel.

#28

/proc/sys/kernel/sched_autogroup_enabled:1
/proc/sys/kernel/sched_child_runs_first:0
/proc/sys/kernel/sched_latency_ns:18000000
/proc/sys/kernel/sched_migration_cost_ns:500000
/proc/sys/kernel/sched_min_granularity_ns:2250000
/proc/sys/kernel/sched_nr_migrate:32
/proc/sys/kernel/sched_rr_timeslice_ms:100
/proc/sys/kernel/sched_rt_period_us:1000000
/proc/sys/kernel/sched_rt_runtime_us:950000
/proc/sys/kernel/sched_schedstats:0
/proc/sys/kernel/sched_tunable_scaling:1
/proc/sys/kernel/sched_wakeup_granularity_ns:3000000

#29

just curious if you tinker those things on a rpi if they would make a difference – on a standard x86 system it would, (whether you are using RT or non-RT both affect scheduling)

echo 1000000 > /proc/sys/kernel/sched_min_granularity_ns
echo 1000000 > /proc/sys/kernel/sched_wakeup_granularity_ns

– and see if that reduced x-runs…

normally wouldn’t stall the machine, if you go below 1ms with

echo 750000 > /proc/sys/kernel/sched_min_granularity_ns

dunno if that may do good – on a non-rt here this causes an issue… having now a kernel that is rt I don’t get a stall when I go below 1ms for the sched_min_granularity_ns setting

#30

What x-runs? Above he said it’s solid at at 48000/256/2

In any case, I expect the bottleneck is still USB (I/O and IRQ handling) not scheduling in general.

#31

Could be a difference in sessions. I try to keep the complexity of mine way down.

#32

@ardour_fa3cv was asking about what was causing xruns so I presumed he was looking for a way to reduce them, Ardour on Raspberry Pi 4 Model B first impressions and test results
“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.”

with qdbus you can get to list xruns that could be happening outside ardour,
“/usr/lib/qt5/bin/qdbus org.jackaudio.service /org/jackaudio/Controller org.jackaudio.JackControl.GetXruns”
– is for jackdbus though, I don’t think that would work if running jackd… – you probably can get verbose output I think from where jackd is running…

The term “preemption” is the scheduling-decision the kernel takes – it can be tuned to do preemption various ways, tailored for Desktop, Server or RT – but for RT the kernel needs to be given patches. RT patches are not available for each kernel release, it is only available at certain intervals, so you can only use a kernel tree available at that interval release if you want to use its available RT patches, (the RT patches come in a single .patch.gz file)

https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.2/
https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.2/patch-5.2.21-rt13.patch.gz
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.2.21

I haven’t compiled the latest, but I’ve done so with 5.2.14,
prior to doing patches, the available preemption models lists just 3 preemption models (no rt),

2019-10-17_22-40
2019-10-17_22-40.png891×543 29.2 KB

After you apply the rt patches, the make menuconfig now shows two newly available RT preemption models.

2019-10-17_22-38
2019-10-17_22-38.png803×489 33.3 KB

What I found was I can significantly reduce x-runs by using the same CFS settings as from avllinux and UbuntuStudio which use the same sched_* parameters,

sched_latency_ns:6000000
sched_migration_cost_ns:500000
sched_min_granularity_ns:750000
sched_wakeup_granularity_ns:1000000
sched_nr_migrate:8
sched_rr_timeslice_ms:100

fwiw I am able to reduce further x-runs even more by applying changes to sched_features …
(i use these at the end of /etc/rc.local – debian)

echo “NO_WAKEUP_PREEMPTION” > /sys/kernel/debug/sched_features
echo “HRTICK” > /sys/kernel/debug/sched_features
echo “DOUBLE_TICK” > /sys/kernel/debug/sched_features
echo “NO_GENTLE_FAIR_SLEEPERS” > /sys/kernel/debug/sched_features

Since rpi’s use an SoC chip I don’t know if these changes make a difference… but these changes make a day and night difference on the systems I use.

(If you’re not using an RT kernel, don’t bother to apply anything other than NO_WAKEUP_PREEMPTION and NO_GENTLE_FAIR_SLEEPERS, as you are likely to stall the machine.)

According to the kernel devs, having sched_wakeup_granularity_ns as 0 is also legitimate. It similarly does the same thing as NO_WAKEUP_PREEMPTION…

I had to tune things multiple times until I was able to mitigate x-runs… Prior occasions I would get “zero” x-runs when not doing any recording (something as simple as a Midi track, just recording midi note values with a usb midi keyboard)… I could do live-tests of digital/midi synths with a usb midi keyboard and never get any x-runs, as soon as I hit the “record”, bam floods of x-runs…

“I compiled and installed raspbian with kernel preemption turned on” << that raises questions because that is 100% related to how the scheduling is applied… though it’s not clear which “preemption” model was recompiled…

Preemption is done at different styles with the linux kernel, … it’s likely too finnicky to talk about on here, but you are changing the scheduler behaviour of the kernel when you recompile it with a different preemption model.

@x42
“In any case, I expect the bottleneck is still USB (I/O and IRQ handling) not scheduling in general.”

ardour_fa3cv brought it up actually and I just added more things to fine-tune the scheduler, which I would of thought he was after… you probably have good reservations about it, but the fact is you don’t say anything to @ardour_fa3cv who was doing exactly that — changing the kernel’s preemption model in general changes the scheduler. And he recompiled a whole kernel just for that, yet you said nothing about it.

I’m only trying to help another user who was already doing something as large as recompiling their kernel and providing settings known to be valid and “safe” from the AvlLinux and UbuntuStudio – and I think(or would of thought) such advice can be encouraged rather than discouraged.

@paul dunno why @x42 said nothing to @ardour_fa3cv about what he told me, when @ardour_fa3cv is doing 100% just that. I don’t know what it is with @x42 , but I did not bring up the topic of scheduling when a user says they completely recompile their kernel with a different preemption model. Be honest @x42 , I’m here to help and you know it. Just tell me if these topics are permitted on this forum because you are lying to me when you try to make it look like I brought up the idea of “scheduling” when a user here recompiles a whole new kernel with a different “scheduling” preemption model. Be honest.

The RT patches do all kinds of things in prioritizing IRQ and RCU things, a user can easily grep through the patch package and see full of commit comments about them. So the “bottleneck” is dealt with by recompiling things, and that is never mentioned… But I never encouraged the topic when it was already strongly indicative to begin with when a user recompiles a kernel’s sheduling preemption model. This is just @x42 trying to make me look stupid again.

and I help pay for your work @x42 – I contribute financially to ardour monthly and I am an owner of mixbus32cc, so show a littlle dam respect.

cheers

Is it really possible to get down to 0 Xruns?
#33

@ahms This post is another mess, a large ill-formatted braindump with mostly off-topic content that will likely help nobody and only confuse users who will visit this thread in the future.

I have a hard time to read it and extract useful relevant information.
There are some interesting bits that you mention in there, though. It would be great if you could perhaps edit it, try to be more concise and ideally also use some discourse-formatting.

I have no intention of doing that. I’m sorry if you feel that way.
I do evaluate content of the post, regardless of who writes it.

I’m sorry, but respect cannot be bought by money.

#34

funny man. You could of told @ardour_fa3cv he was doing just that. He’s the one who brought up the encouraging notion of changing his “scheduler”, not me. You should be telling him what you told me. capish?
You are wrong in telling me it has nothing to do with the scheduler, when @ardour_fa3cv was completely doing just that by recompiling his KERNEL.