.deb to optimize Linux Mint (Debian) for Audio Pro

[sunrat]

Yeah, I saw it and noticed it. I'm really surprised that the RealtimeConfigQuickScan script does it this way instead of just checking the output of the uname -a command.

Well, well, always cool to learn something new and I will use RealtimeConfigQuickScan with slightly more suspicion from now on.

I imagine the kernel config file is intended to reflect the options with which the kernel is compiled, but I doubt it was intended to be edited randomly after installation. In all situations where the config file has not been altered since installation RealtimeConfigQuickScan will report correctly.
Another unrelated issue with RealtimeConfigQuickScan is that it advises to set swappiness in a file in /sys/ which is only temporary . The permanent way, which thankfully OP has included in their script, is to set it in /etc/sysctl.conf .

[basstrombone]

4- The script checks if there is a low latency kernel installed. If it does, it alters the /boot/config-`uname -r` in order to ad the RT mode. This is achieved by modifying the following parameters:

CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y
If no low latency kernel has not been located, the script proceeds with its installation.

I'm no expert, but doesn't the kernel need to be recompiled after you change its config?

The rest of the scripts are basically what I do to set up an audio workstation, using Debian Buster atm.

Hello Sunrat,

According to the Ubuntu,Linux Mint and Debian Developers there's no need to recompile de Kernel.

I'll copy a Link here that explains that. If you check it out you'll see.

The script (the deb. package) during installation, verifies if there is a RT and Low Latency Kernel installed. If not, it installs all the dependecies needed.

Here are the links:

Ubuntu:

https://help.ubuntu.com/community/Ubuntu...TimeKernel

Debian

https://wiki.debian.org/DebianMultimedia



I hope it helps to clarify. And We do love to see if you could run a test on a fresh install, and let us know ok?


The goal of this package is to facilitate the life of newbies (like I was) and many people patiently assited me here at the forum

We'll make a video with and without the usage of the package to check if anyone could run Ardour without any of these modifications

---

4- The script checks if there is a low latency kernel installed. If it does, it alters the /boot/config-`uname -r` in order to ad the RT mode. This is achieved by modifying the following parameters:

CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y
If no low latency kernel has not been located, the script proceeds with its installation.

I'm no expert, but doesn't the kernel need to be recompiled after you change its config?
...

Hello Jostein and sorry for the delay on answering you,


According to the Ubuntu,Linux Mint and Debian Developers there's no need to recompile de Kernel.

I'll copy a Link here that explains that. If you check it out you'll see.

The script (the deb. package) during installation, verifies if there is a RT and Low Latency Kernel installed. If not, it installs all the dependecies needed.

Here are the links:

Ubuntu:

https://help.ubuntu.com/community/Ubuntu...TimeKernel

Debian

https://wiki.debian.org/DebianMultimedia



I hope it helps to clarify. And We do love to see if you could run a test on a fresh install, and let us know ok?


The goal of this package is to facilitate the life of newbies (like I was) and many people patiently assited me here at the forum

We'll make a video with and without the usage of the package to check if anyone could run Ardour without any of these modifications




As far as I know, no.

Yes, you have to recompile it. The config file consists of the settings used for compiling the kernel.

---

This script is not something I would use or recommend in its present state. It probably won't harm anything but it won't do what it is supposed to.
The kernel configs do nothing. As Jostein and I have mentioned, you need to recompile a kernel to bless it with new parameters.
The cron job to check every hour for a new kernel is pointless and may even degrade performance. Audio kernels don't generally need to be updated as long as they work.
It could be useful with some minor changes. I look forward to v.0.2 and beyond.

Hello Sunrat,

According to the Ubuntu,Linux Mint and Debian Developers there's no need to recompile de Kernel.

I'll copy a Link here that explains that. If you check it out you'll see.

The script (the deb. package) during installation, verifies if there is a RT and Low Latency Kernel installed. If not, it installs all the dependecies needed.

Here are the links:

Ubuntu:

https://help.ubuntu.com/community/Ubuntu...TimeKernel

Debian

https://wiki.debian.org/DebianMultimedia



I hope it helps to clarify. And We do love to see if you could run a test on a fresh install, and let us know ok?


The goal of this package is to facilitate the life of newbies (like I was) and many people patiently assited me here at the forum

We'll make a video with and without the usage of the package to check if anyone could run Ardour without any of these modifications

---

One does in general not need a realtime kernel as long as one uses a low latency one or only mixes or uses the mouse for MIDI work. But when you have old hardware or for example for real plays and/or records soft (synths) players, such as Pianoteq or the wonderful Diva from u-he, then you really should have an RT kernel, the same applies if you do not have a decent mixer or a sound card with HW monitor capabilities and records vocals. I can run down 32 frames, 2 periods at 44100 on my system, and do usually not get X-runs, but the 64 periods setting is stable on my systems.

For one that are used to the command line or for different reasons are used to compile programs, a compilation of a kernel is not difficult. For most users, a new version of a patched kernel will probably work, but I always compile an RT kernel that is close to my distro's. So my main studio is based upon Kubuntu 18.04, the RT-kernel is 4.19.59-rt24. A 5.x based kernel will work just fine too. On my laptop, I have Kubuntu 20.04 with a 5.4.34-rt21 kernel.

If you do not want to compile the kernel, the RT from AV-Linux will probably work fine.

Justain,

I've been using these configs and recording many albuns in old machines including my 2012 iMac runing Linux Mint 19.3 Kernel 4.15.0-112-lowlatency with the script. I mix Large Brass Ensembles, Chamber music, Jazz Ensenbles. I have recorded (not with beat) but regular recording (without software monitoring) 8 Channels simoultaneously 24Bit @ 48Khz with an old mini pc with those types of settings and without these, It never recorded anything. As a matter of fact, Ardour would not even open.

I beieve that we could exchange more informations because many users will benefit from your comments we do appreaciate it

[sunrat]

According to the Ubuntu,Linux Mint and Debian Developers there's no need to recompile de Kernel.

I'll copy a Link here that explains that. If you check it out you'll see.

Sorry dude, those links don't explain that at all. In fact the second one has a section explaining why you probably don't need an RT kernel these days as most of the RT patches which used to be applied are now incorporated in the mainline kernel.
I was conversing with raboof, developer of RealtimeConfigQuickScan script, last week after I made a minor commit for it on Github and mentioned your script. He agrees that editing the kernel config does nothing to make the kernel RT unless a new kernel is subsequently compiled using the new config. The script checks the config file, not the kernel itself, so the notification of active RT kernel is incorrect and misleading. He said the config file should be read-only and not edited unless copied for compiling.
The rest of your script is quite good but unless you acknowledge what I'm saying is true (or somehow prove I'm wrong, for which I would humbly eat pie) , I can't use or recommend it. As I said earlier, looking forward to your script v0.2.

[Jostein]

I've been using these configs and recording many albuns in old machines including my 2012 iMac runing Linux Mint 19.3 Kernel 4.15.0-112-lowlatency with the script. I mix Large Brass Ensembles, Chamber music, Jazz Ensenbles. I have recorded (not with beat) but regular recording (without software monitoring) 8 Channels simoultaneously 24Bit @ 48Khz with an old mini pc with those types of settings and without these, It never recorded anything. As a matter of fact, Ardour would not even open.

This is a coincidence or has other reasons unless you are doing some black magic! What you say here is not the way the kernel works. That configuration files are only for information about how the kernels configurations were before they were compiled and are commonly used when one wants to compile a new kernel based upon an existing one - making the old settings as presets before configuring a new one to compile. By altering and changing the contents of these files, you are potentially corrupting other people's settings. To change these files is a big no-no.

The kernel basically has a bunch of functions and settings, statically compiled in the kernel itself or as modules that can be loaded to the system. These RT settings are compiled statically and set inside the kernel.

EDIT: As I'm now reading about the subject, it turns out that some relevant settings can be passed to the kernel as boot parameters, either manually by pausing grub from booting the kernel and passing the settings or set them in the grub configuration file. But you still have to compile a RT-kernel with the functions enabled as far as I can see.

[madmaxmiller]

EDIT: As I'm now reading about the subject, it turns out that some relevant settings can be passed to the kernel as boot parameters, either manually by pausing grub from booting the kernel and passing the settings or set them in the grub configuration file. But you still have to compile a RT-kernel with the functions enabled as far as I can see.

Yes, to accept parameters the kernel must know these parameters and have the code compiled in to respond to them. Many of them are actually to exclude problematic settings, not performance enhancements.
I found an overview of common parameters here:
http://distro.ibiblio.org/fatdog/web/faq...tions.html

MMM

[keefaz]

I don't use rt kernel but I use "threadirqs" kernel command line parameter along with the rtirq script that set higher priority for firewire and snd IRQ threads (my soundcard is firewire)
I made a script started by qjackctl that kills pulseaudio, set cpu scaling governor to performance and start rtirq
When qjackctl stops, the script does the opposite

[ethanay]

I don't use rt kernel but I use "threadirqs" kernel command line parameter along with the rtirq script that set higher priority for firewire and snd IRQ threads (my soundcard is firewire)
I made a script started by qjackctl that kills pulseaudio, set cpu scaling governor to performance and start rtirq
When qjackctl stops, the script does the opposite

That sounds great. Would you be willing to share the script?

I argued over here that there is a good case to be made for a performance tweaking front end that allows a user to seamlessly enter and exit discrete performance states based on expected or planned work load: https://pop-planet.info/forums/threads/p...rface.739/

EG there is a strong case for disabling hyperthreading during low latency audio work, but it generally makes sense to keep it enabled.

I generally use the low latency kernel with rtirq. Unfortunately the .deb of rtirq is like 5 years old! The updated versions really need to be packaged for .deb.

[Sthauge]

EG there is a strong case for disabling hyperthreading during low latency audio work, but it generally makes sense to keep it enabled.

No it's not. Having HT on can make a lot of XRUNs if the session is large enough. With small sessions HT is probably ok, but do not bring that much of advantages. Even with small session you can get XRUNs if your unlucky.

HT is not easy to explain if you're not known to basic processor design, but we might see it this way:
If a normal core = A + B then a hyper-threading core is more like A + 2 x B. They CAN execute two threads simultaneously as long as both threads don't need A. When doing audio work you will typically need a lot of A and you will sooner or later get constraints on A that again will make XRUNs

We are discussing RT processing here. If you have 4 real cores, HT will give you 8 virtual cores. Virtual cores in a RT environment do not make much sense.

I use a script that disable HT when Jack starts and enable HT when Jack stops. I see less DSP load and huge reduction or none XRUNs having HT off.

[sunrat]

I use a script that disable HT when Jack starts and enable HT when Jack stops.

That could be helpful to share for a few people if you can. Not me personally though, I specifically chose a processor without hyperthreading for my production rig.

I didn't even realise HT could be disabled by script, thought it was a UEFI/BIOS setting.

[madmaxmiller]

I didn't even realise HT could be disabled by script, thought it was a UEFI/BIOS setting.

If you remember good old BeOS - that could switch CPUs on and off ad libitum via mouse click. I ran it on a Dual P III / 350 MHz then and it was fast! But... history had it that this was another victim of the mighty Apple religion (the way all Apple "forks" go...).

MMM