New wiki article on installing a Linux audio system

[autostatic]

Hello,

I've added a new article to the linuxaudio.org Wiki on how to install a Linux audio system: https://wiki.linuxaudio.org/wiki/system_build

If there are any mistakes or things missing then let me know. Any feedback is welcome!

Jeremy

[runiq]

Please be careful with mitigations=off. I understand the performance win is substantial, but Spectre/Meltdown are not fun. They can be exploited just by going to the wrong website, for example. And I can only speak for myself here, but experimenting with various plugins and settings and random stuff downloaded from the internet is par for the course. So I would leave the mitigations on, or at least provide a note with some links to added context.

[autostatic]

You're right, I'll add a note, just like I did with the System Configuration wiki. Thanks for pointing that out!

Edit: added a warning

[ForrestH]

A somewhat safe way to do it would be by building your own kernel and disabling both mitigations and your network access; e.g. my ethernet module is the e1000e, so I would set my .config with

CONFIG_E1000E=n
CONFIG_CMDLINE="mitigations=off"

[Kott]

A somewhat safe way to do it would be by building your own kernel and disabling both mitigations and your network access; e.g. my ethernet module is the e1000e, so I would set my .config with

CONFIG_E1000E=n
CONFIG_CMDLINE="mitigations=off"

isn't unplugging a patch-cord is a much more faster solution?

[sunrat]

Nice article!
A couple of notes:

• In the blacklist section you wrote "Blocklist" twice.
• At least a small swap is recommended even with lots of RAM. As a regular contributor at Debian forums, there have been several issues posted when no swap is used which were solved with swap of say, 1GB.
• Installing Liquorix with the script can cause issues with dkms module builds such as Nvidia when a new kernel version is automatically installed. I just add the Liquorix repo to sources manually and update the kernel occasionally. For example, The current 6.5 Liquorix kernel won't build nvidia with the current driver version on Bullseye but 6.4 does.
• Last I checked, KX were not updating a number of plugins so I prefer to check if there is a more recent version upstream. They were updating their own applications such as Carla, and certain others. lsp-plugins for example is v.1.2.4 on KX whereas upstream is 1.2.12; dragonfly reverb on KX is 3.2.7, upstream is 3.2.10.

[ForrestH]

isn't unplugging a patch-cord is a much more faster solution?

In my case I'd have to go find a flashlight.

[Linuxmusician01]

Article is specifically for Debian 12. So the Wiki might deprecate soon. No mention of PipeWire (I do see some mention of Jack) whereas Deb 12 AFAIK switched to PW (link to article about it).

[autostatic]

Article is specifically for Debian 12. So the Wiki might deprecate soon.

I intend to write a new article then with Debian 13 as a starting point and archive the current article.

No mention of PipeWire (I do see some mention of Jack) whereas Deb 12 AFAIK switched to PW (link to article about it).

XFCE uses PulseAudio on Debian 12.

[autostatic]

Nice article!

Thanks for the feedback!

A couple of notes:

• In the blacklist section you wrote "Blocklist" twice.

Rephrased that.

- At least a small swap is recommended even with lots of RAM. As a regular contributor at Debian forums, there have been several issues posted when no swap is used which were solved with swap of say, 1GB.

What kind of issues were reported? Any links? To be honest didn't really dive into this, I don't use swap myself and haven't had any issues regarding swap yet.

- Installing Liquorix with the script can cause issues with dkms module builds such as Nvidia when a new kernel version is automatically installed. I just add the Liquorix repo to sources manually and update the kernel occasionally. For example, The current 6.5 Liquorix kernel won't build nvidia with the current driver version on Bullseye but 6.4 does.

I will change that and add a manual way of installing the Liquorix kernel, not very fond of the script myself to be honest.

- Last I checked, KX were not updating a number of plugins so I prefer to check if there is a more recent version upstream. They were updating their own applications such as Carla, and certain others. lsp-plugins for example is v.1.2.4 on KX whereas upstream is 1.2.12; dragonfly reverb on KX is 3.2.7, upstream is 3.2.10.

Agreed, but it's still a good starting point I think.

[novalix]

Hi,

regarding the question about swap space, there are different reasons to use it even with "enough" ram.

Firstly it's obviously a safety net for maybe not foreseen use cases. Like you start of with the plan to record and mix "real" instruments and over the course of time enter the world of virtual instruments with big sample libraries. Suddenly your 16GB of ram may start to melt away and if you hit the threshold it goes boom.

And then there is a slight misconception about swapping being slow brought over from the olden days.
The linux kernel's virtual memory concept swaps out pages which it identifies as being idle from the memory cache. When no swap space is available and the cache runs full those idle pages are simply deleted as the cached program data can also be read from the file system. If the program needs that data after a while and can't find it in the ram cache it is still much faster to read it from a swap space than loading it from the file system.

So there might be situations where a system with swap space acts faster than one without.

https://www.kernel.org/doc/html/latest/ ... cepts.html

[sunrat]

Thanks @novalix , yes one consideration is running out of RAM. However that's not the main issue I recall from Debian forums. I'm not going to search for the relevant posts, but my recollection is that certain applications expect and use swap in their normal operation and may fail without it. Probably those certain applications were not audio applications however and in the past I have run my system without swap with no noticeable issues.
My current system has 16GB RAM and 4GB swap partition. I just checked and after about 9 days uptime it shows 1.6GB swap being used even though it rarely uses over 4GB RAM. It surprised me it was so much actually.
Bottom line is it doesn't hurt to have swap so there's no point in not doing so. If you run rtcqs it recommends to set swappiness at 10 (I settled for 15) but I investigated that some time ago and don't think it matters much, and is also widely misunderstood as to what it actually does.

[Linuxmusician01]

At the moment I'm (finally) KXStudio repository "free". I do have 'Carla' installed, but via the regular Ubuntu 20.04 repo's. KXStudio in the past was the repo for a lot of audio stuff. But - as with a lot of one person projects - it got to be less after a few years. Certain apps disappeared and it couldn't be installed as a complete distro anymore. And for some reason it became more than a single repo over time, etc.

So for a minimal audio setup I would not recommend activating the KXStudio repo even though the app 'Carla' is absolutely obligatory for Linux Audio.

[autostatic]

Firstly it's obviously a safety net for maybe not foreseen use cases. Like you start of with the plan to record and mix "real" instruments and over the course of time enter the world of virtual instruments with big sample libraries. Suddenly your 16GB of ram may start to melt away and if you hit the threshold it goes boom.

Before that the OOM killer has probably already kicked in. Not much difference between those two situations, blocking could also be caused by the OOM killer killing processes your system relies upon. But getting to the OOM killer and having some swap does allow you to have a bit more room to figure out what the cause of the memory drain might be.

And then there is a slight misconception about swapping being slow brought over from the olden days.
The linux kernel's virtual memory concept swaps out pages which it identifies as being idle from the memory cache. When no swap space is available and the cache runs full those idle pages are simply deleted as the cached program data can also be read from the file system. If the program needs that data after a while and can't find it in the ram cache it is still much faster to read it from a swap space than loading it from the file system.

That's true, but it's also about anonymous pages and that's where swap can really make a difference.

So there might be situations where a system with swap space acts faster than one without.

Agreed.

https://www.kernel.org/doc/html/latest/ ... cepts.html

I'd like to toss in this one: https://chrisdown.name/2018/01/02/in-de ... -swap.html

So I'm going to revise my stance on swap, get a better understanding of Linux memory management and improve the relevant wiki pages.

[autostatic]

Bottom line is it doesn't hurt to have swap so there's no point in not doing so. If you run rtcqs it recommends to set swappiness at 10 (I settled for 15) but I investigated that some time ago and don't think it matters much, and is also widely misunderstood as to what it actually does.

As the author of rtcqs I will look into that option too. The default of 60 is probably OK in most cases and setting it to 10 is a remnant of a past where everyone was still using spinning disks.