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

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/

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

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

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

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

1 Like

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

Seablade

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.

/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

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

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.

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

@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),

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

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

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

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.

Whether or not the bulk of this post is useful (which is debatable, but certainly open for debate), the closing couple of paragraphs contain unacceptable language.

Further use of language like this will see you banned from these forums.

I understand that, but that is harrassment. x42 knows what a preemption choice is with recompiling his kernel. It’s not the first time he doesn’t acknowledge contributions I make and try to help users on here.

You’re sailing right along the edge here in terms of language.

x42 does not engage in harassment.

Accusing another forum user of harassment is more or less a step too far, especially in this case.

You do not need to acknowledge who is right. But I shouldn’t be told I am wrong when another user brought it up with a whole kernel recompilation and then I am told I brought up the topic. I’ve been a Linux for a long time and obviously the “topic” I get discouraged from working on is something that was already strongly indicative already when a user recompiles an entire kernel. This is just wrong in plain sight – it insults my intelligence tbh, I’ve been compiling kernels for over a DECADE, so I know at the very least when I talking about some of the things I pointed.

None of that requires accusing another forum user of harassment, or of trying make you look stupid, or demanding that they “show respect”.

As has been noted here and elsewhere, your longer posts seem to take the form of substantial information dumps, the contents of which tend to be of mixed relevance.

Nobody is telling you that you are stupid or know nothing, merely that the form of these posts is less useful than they could be, and in the worst case scenario, actually a net negative because of the confusion they can cause.

1 Like

I can email you my LPIC level credentials. I have certification for the “things” I point out to. Whatever — I still feel insulted.