Category Archives: Linux

Gentoo eudev adopted by Eudev Project

A recent LinuxQuestions thread discusses the depreciation of the eudev fork which was created by Gentoo a few years back in order to keep systemd at bay. This step by Gentoo sparks some serious doubts among LQ members about what Slackware should do – is the inclusion of systemd near, now that eudev is dead?

Short recap: In November 2015 Slackware replaced its no longer maintained original udev with this new eudev (a standalone extract of udev out of the systemd sources but modified so that every dependency on systemd is removed). This change was actually my chance to announce the liveslak project as a ‘celebration to say farewell to udev‘.
In November of 2020, a similar event happened when Slackware replaced ConsoleKit2 with elogind – a standalone copy of the logind code extracted from systemd and with all dependencies to systemd removed. Both events were meant to keep Slackware free of systemd, at least for a while… who can stem the flow of water.

But there is good news. Yesterday, a collaboration between Alpine, Devuan and Gentoo contributors has announced their adoption of eudev and a new repository has been created where the new project will further develop eudev: https://github.com/eudev-project/eudev/blob/master/README.md . Let’s give these folk our best wishes!

Eric

How to ‘un-google’ your Chromium browser experience

… Aka the future of Chromium based (embedded) browsers


On March 15th 2021, Google is going to block non-Google chromium-based browsers from accessing certain “private Google Chrome web services” by unilaterally revoking agreements made with 3rd parties in the past.
Meaning, every Chromium based product not officially distributed by Google will be limited to the use of only a few public Google Chrome web services.
The most important service that remains open is “safe browsing”. The safe browsing feature identifies unsafe websites across the Internet and notifies browser users about the potential harm such websites can cause.

The most prominent feature which will be blocked after March 15th is the “Chrome Sync”. This Chrome Sync capability in Chromium based browsers allows you to login to Google’s Sync cloud servers and save your passwords, browsing history and bookmarks/favorites to your personal encrypted cloud vault inside Google’s infrastructure.
Extremely convenient for people who access the Internet using multiple devices (like me: Chrome on a few Windows desktops, Chromium on several Slackware desktops and laptop and Chrome Mobile on my Android smartphone) and who want a unified user experience in Chrome/chromium across all these platforms.
In order to boost the development of Chromium-based (embedded) browser products, Google made deals with 3rd parties as far back as 2013 (from what I could find) and spiced the API keys of these 3rd parties with access to crucial Google Webservices providing features that would draw users to these products.
If you offer a product that calls upon Google’s Web Services there is a monetary cost involved once the number of your users’ connections exceeds the monthly upper limit for free usage. So on top of providing us access to these Google APIs (in the case of Open Source Distro Chromium packagers) the Chromium team also substantially increased the non-billed monthly API consumption by the users of our distros’ Chromium browsers. This helped to prevent us poor distro packagers from being billed for Cloud API usage in case our browser packages gained popularity.
And then, early 2021, some Google white-collar people decided they had enough of these freeloaders.

When Google dropped the bomb on us – on the distro packagers in particular – a fierce discussion started in two Google Groups (posts in one group are mostly duplicated  into the other group): Chromium Packagers and Chromium Embedders. It’s like talking to corporate drones – every question we asked is replied to with the same bogus standard texts. Arrogance to the max!
Even more poignant is a parallel discussion in Chromium Embedders, where some large electronics manufacturers discovered that some of their commercial products are similarly affected. Consumer Electronic products that ship with browser-based embedded applications like Smart TV’s often use CEF (Chromium Embedded Framework) and Google will block access for CEF products to their “private” Chrome APIs just like it’s going to do with distro browsers – they are all based on the same Chromium source code and are all non-Google products.

If you wonder what happened to the Google motto “Don’t be Evil” – in 2018 that phrase was removed from the employee Code of Conduct. And indeed, looking at the discussions in aforementioned topics the top brass feels completely ‘senang‘ throwing us distro packagers under the bus while at the same time chastising us because apparently we do not adhere to their Code of Conduct.

Enough of all the bullshit – let’s look into the future. What can we do as Linux users, and what will I do as a distro packager.

Let me be clear: I do not want to take choices away from you. You can keep using Chromium, you can switch to Chrome, you can investigate whether Vivaldi or Brave (two chromium-based browsers with their own Google-free implementation of cloud sync) are better options for you.
I will however have to deal with the fact that I can no longer build a Chromium package that offers a synchronization of your private browser data out of the box. So what I will discuss in the remainder of this article are possibilities.

Chromium packages for Slackware are here to stay

… but I will remove my personal Google ID and corresponding secret from my chromium package. They will have been invalidated anyway on March 15 and are therefore useless. What I will leave in, is my “Slackware Chromium API Key” which keeps the “safe browsing” functionality alive if you use my browser.

I want to state here that from now on, I also explicitly forbid others / distros to re-use and re-package my binaries in order to  make them part of their own Linux Distribution: thinking of Slacko Puppy, Porteus, Slint and others. If needed I will use “cease & desist” messages if people refuse to comply. I am not going to pay Google for the use of my binaries in distros that I do not control. The use of my API key is automatic if you run my Chromium binaries, and it involves a monthly cost if Google’s Could APIs get called too much. I already had to negotiate several times with the Chromium people to avoid getting billed when their policies changed. So get your own API key and compile your own version of the browser please.
You can request your own APIkey/ID/string in case you did not realize that! You’ll get capped access to Google API services, good for a single person but still without access to Cloud Sync. If you introduce yourself to the Chromium team as a distro packager, they may help you with increasing your browser’s un-billed API usage.

There’s a public discussion in the Google Group threads that I referred to above, about your personal use of the official Google API keys. This could offer a way out of the blockade and would allow you to keep using Chrome Sync in a Chromium browser even after the distro packagers’ API keys have been invalidated. These official Chrome API key/ID/secret strings are contained as clear-text strings in the public chromium source code for a long time already!
While I am not going to advocate that you should do this, it is up to you (the individual end user of a Chromium-based browser) to find those strings online and apply them to your browser’s startup environment.

Let me explain a bit. When I compile Chromium, my personal API key and Google client-ID are being embedded in the resulting browser binary, and that’s why everything works so nicely out of the box. In future I will not be embedding my client-ID anymore, but my API key for the browser will remain. That his how Safe Browsing will still work (it’s associated to the API key) but Chrome Sync will stop working (because that’s associated with the Client-ID).
The good news is that Chromium browsers will check the environment when they start up, and look for specific variables that contain a custom API key and client-ID. My chromium package is built in such a way that it is easy to add such customization, by creating a “.conf” file in directory “/etc/chromium/”.
In the Slackware package for Chromium, you will find an example of how to apply such an APIkey/ID/secret combo. Just look at the file “/etc/chromium/01-apikeys.conf.sample”. If you remove the “.sample” suffix this file will then define three environment variables on startup of Chromium that tell the browser to use a specific service configuration.
And you  can also copy the Google Chrome key/id/secret into that file and then it’s as if you are using a Chrome browser when talking to Google’s cloud services.

An ‘un-googled’ browser experience

The above API blocking scenario is a “win/lose” scenario as far as I am concerned. For Google it is a “win”: they still get to collect the data related to your online activities which they can monetize. And you “lose” because in return Google won’t allow you to use their cloud sync service any longer. That is not acceptable. And it lead to a bit of research into the possibilities of turning this fiasco into a “win” for the user.
Turns out that there’s is actually an existing online project: “ungoogled-chromium – a lightweight approach to removing Google web service dependency“.
High-over: the “un-googled chromium” project offers a set of patches that can be applied to the Chromium source code. These patches remove any occurrence of Google Web Service URLs from the source code which means that the resulting browser binaries are incapable of sending your private data into Google datacenters. Additionally these patches bring  privacy enhancements borrowed from other Chromium derivatives like the Inox patchset, Debian’s Chromium, Iridium browser and Bromite.
Not just a “win” for the user but a “lose” for Google. They basically brought this down on themselves.

My conclusion was that a removal of Google associations from Chromium and at the same time improving its privacy controls is what I must be focusing on in future Chromium packages.

During my research I did look at existing alternative Chromium browser implementations. They all have their own merits I guess. I do not like to switch to Vivaldi since I think its development process is hazy i.e. not public. Only its complete release tarballs are downloadable. Or Brave – its sources are not available at all and it tries to enforce an awards system where you are encouraged to view ads – I mean, WTF? If I wanted to run a browser compiled by another party that tries to use me for their own gain, I could just stick with the official Chrome and be happy. But that is not my goal.

What I did instead was to enhance my chromium.SlackBuild script with a single environment variable “USE_UNGOOGLED” plus some shell scripting which is executed when that variable is set to ‘true’ (i.e. the value “1”). The result of running “USE_UNGOOGLED=1 ./chromium.SlackBuild” is a package that contains an “un-googled” Chromium browser that has no connection at all to Google services.
I make that package available separately at https://slackware.nl/people/alien/slackbuilds/chromium-ungoogled/

Be warned: using un-Googled Chromium needs some getting used to, but no worries: I will guide you through the initial hurdles in this article. Continue reading! And especially read the ungoogled-chromium FAQ.

The first time you start my chromium-ungoogled it will create a profile directory “~/.config/chromium-ungoogled” which means you can use regular Chromium and the un-googled chromium in parallel, they will not pollute or affect each other’s profiles.

You’ll notice as well that the default start page points to the Chrome Web Store but the link actually does not work. That’s unfortunate but I decided not to look into changing the default start page (for now). Patch welcome.

Which leads to the first question also answered in the above FAQ: how to install Chrome extensions if the Chrome Web Store is inaccessible?
The answer allowing direct installations from the Web Store afterwards is to download and install the chromium-web-store extension (Chrome extensions are packed in files with .crx suffix). You have to do this manually but the instructions for these manual installation steps are clear. Then, any subsequent extensions are a lot easier to install.

Another quirk you may have questions about is the fact that un-Googled Chromium seems to forget your website login credentials all the time. Actually this is done on purpose. FAQ #1 answers this: Look under chrome://settings/content/cookies and search for “Clear cookies and site data when you quit Chromium“. Disable this setting to prevent the above behavior.

Watching Netflix, Hulu or Disney+ content will not work out of the box, you’ll have to install the Widevine CDM library yourself. If you have been a Slackware user for a while, you may recall that I used to provide chromium-widevine-plugin packages, until the capability to download that plugin all by itself was added to Chromium source code by Google. Well… the un-Googled Chromium removed that capability again but I have updated my package repository with a version of the widevine-plugin that works with with the un-Googled browser.

Safe browsing is not available in un-Googled Chromium, since that too is a service provided by Google. Recommended alternatives are uBlock Origin or uMatrix.

Sync your browser data to an online service which is under your own – not Google’s – control

Now that we said good-bye to Google Cloud Sync, can  we still sync our passwords, bookmarks and browsing history to a remote server and access these data from multiple browsers? Yes we can!
Even better, we can sync that data to a place that is under our own control. Multiple computers using the same synchronized data will give you the same experience as your prior usage of Google Cloud Sync. This will then also not be limited to Chromium based browsers – Mozilla based browsers are able to access the same centrally stored data. Win!

The question is then: how to implement it? Is this something you can do without being an IT person or a Slackware Guru?
I will show you that the answer is “yes”, in a follow-up article dealing with keepassxc and xbrowsersync.

Have fun! Eric

Google muzzles all Chromium browsers on 15 March 2021

Ominous music

A word of caution: long rant ahead. I apologize in advance.
There was an impactful post on the Google Chromium blog, last friday.  I recommend you read it now: https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

The message to take away from that post is “We are limiting access to our private Chrome APIs starting on March 15, 2021“.

What is the relevance I hear you ask.
Well, I provide Chromium packages for Slackware, both 32bit and 64bit versions. These chromium packages are built on our native Slackware platform, as opposed to the official Google Chrome binaries which are compiled on an older Ubuntu probably, for maximum compatibility across Linux distros where these binaries are used. One unique quality of my Chromium packages for Slackware is that I provide them for 32bit Slackware. Google ceased providing official 32bit binaries long ago.

In my Slackware Chromium builds, I disable some of the more intrusive Google features. An example: listening all the time to someone saying “OK Google” and sending the follow-up voice clip to Google Search.

And I create a Chromium package which is actually usable enough that people prefer it over Google’s own Chrome binaries, The reason for this usefulness is the fact that I enable access to Google’s cloud sync platform through my personal so-called “Google API key“. In Chromium for Slackware, you can logon to your Google account, sync your preferences, bookmarks, history, passwords etc to and from your cloud storage on Google’s platform. Your Chromium browser on Slackware is able to use Google’s location services and offer localized content; it uses Google’s  translation engine, etcetera. All that is possible because I formally requested and was granted access to these Google services through their APIs within the context of providing them through a Chromium package for Slackware.

The API key, combined with my ID and passphrase that allow your Chromium browser to access all these Google services are embedded in the binary – they are added during compilation. They are my key, and they are distributed and used with written permission from the Chromium team.

These API keys are usually meant to be used by software developers when testing their programs which they base on Chromium code. Every time a Chromium browser I compiled talks to Google through their Cloud Service APIs, a counter increases on my API key. Usage of the API keys for developers is rate-limited,  which means if an API key is used too frequently, you hit a limit and you’ll get an error response instead of a search result. So I made a deal with the Google Chromium team to be recognized as a real product with real users and an increased API usage frequency. Because I get billed for every access to the APIs which exceeds my allotted quota and I am generous but not crazy.
I know that several derivative distributions re-use my Chromium binary packages (without giving credit) and hence tax the usage quota on my Google Cloud account, but I cover this through donations, thank you my friends, and no thanks to the leeches of those distros.

Now, what Google wants to do is limit the access to and usage of these Google services to only the software they themselves publish – i.e. Google Chrome. They are going to deny access to Google’s Cloud Services for all 3rd-party Chromium products (i.e. any binary software not distributed by Google).
Understand that there are many derivative browsers out there – based on the Open Source Chromium codebase – currently using a Google API key to access and use Google Cloud services. I am not talking about just the Chromium packages which you will find for most Linux distros and which are maintained by ‘distro packagers’. But also commercial and non-commercial products that offer browser-like features or interface and use an embedded version of Chromium to enable these capabilities. The whole Google Cloud ecosystem which is accessible using Google API Keys is built into the core of Chromium source code… all that these companies had to do was hack & compile the Chromium code, request their own API key and let the users of their (non-)commercial product store all their private data on Google’s Cloud.

Google does not like it that 3rd parties use their infrastructure to store user data Google cannot control. So they decided to deliver a blanket strike – not considering the differences in usage, simply killing everything that is not Google.
Their statement to us distro packagers is that our use of the API keys violates their Terms of Service. The fact is that in the past, several distros have actively worked with Google’s Chromium team to give their browser a wider audience through functional builds of the Open Source part of Chrome. I think that Google should be pleased with the increased profits associated with the multitude of Linux users using their services.
This is an excerpt from the formal acknowledgement email I received (dating back to 2013) with the approval to use my personal Google API key in a Chromium package for Slackware:

Hi Eric,

Note that the public Terms of Service do not allow distribution of the API
keys in any form. To make this work for you, on behalf of Google Chrome
Team I am providing you with:

    -
    Official permission to include Google API keys in your packages and to
    distribute these packages.  The remainder of the Terms of Service for each
    API applies, but at this time you are not bound by the requirement to only
    access the APIs for personal and development use, and
    -
    Additional quota for each API in an effort to adequately support your
    users.

I recommend providing keys at build time, by passing additional flags to
build/gyp_chromium. In your package spec file, please make an easy to see
and obvious warning that the keys are only to be used for Slackware. Here
is an example text you can use:

# Set up Google API keys, see
http://www.chromium.org/developers/how-tos/api-keys .
# Note: these are for ... use ONLY. For your own distribution,
# please get your own set of keys.

And indeed, my chromium.SlackBuild script contains this warning ever since:

# This package is built with Alien's Google API keys for Chromium.
# The keys are contained in the file "chromium_apikeys".
# If you want to rebuild this package, you can use my API keys, however:
# you are not allowed to re-distribute these keys!!
# You can also obtain your own, see:
# http://www.chromium.org/developers/how-tos/api-keys

It effectively means that I alone am entitled to distribute the binary Chromium packages that I create. All derivative distros that use/repackage my binaries in any form are in violation of this statement.

On March 15, 2021 access to Google’s Cloud services will be revoked from my API key (and that of all the other 3rd parties providing any sort of Chromium-related binaries). It means that my Chromium will revert to a simple browser which will allow you to login to your Google account and store your data (bookmarks/passwords/history) locally but will not sync that data to and from your Google Cloud account. Also, location and translation services and probably several other services will stop working in the browser. Effectively, Google will muzzle any Chromium browser, forcing people to use their closed Chrome binaries instead if they want cross-platform access to their data. For instance, using Chrome on Android and Chromium on Slackware.
Yes, Chrome is based on Chromium source code but there’s code added on top that we do not know of. Not everybody is comfortable with that. There was a good reason to start distributing a Chromium package for Slackware!

Now the one million dollar question:

Will you (users of my package) still use this muzzled version of Chromium? After all, Slackware-current (soon to become 15.0 stable) contains the Falkon browser as part of Plasma5, and Falkon is a Chromium browser core with a Qt5 graphical interface, and it does not use any Google API key either. Falkon will therefore offer the same or a similar feature set as a muzzled Chromium.
If you prefer not to use Chromium any longer after March 15, because this browser lost its value and unique distinguishing features for you, then I would like to know. Compiling Chromium is not trivial, it takes a lot of effort every major release to understand why it no longer compiles and then finding solutions for that, and then the compile time is horribly long as well. Any mistake or build failure sets me back a day easily. It means that I will stop providing Chromium packages in the event of diminishing interest. I have better things to do than fight with Google.

Please share your thoughts in the comments section below

FYI:

There are two threads on Google Groups where the discussion is captured; the Chromium Embedders group: https://groups.google.com/a/chromium.org/g/embedder-dev/c/NXm7GIKTNTE  – and most of it (but not all!) is duplicated in the Chromium Distro Packagers group: https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM – I advise you to read the cases made by several distro packagers and especially take good care of how the Google representatives are answering our concerns. There’s more than a tad of arrogance and disrespect to be found there, so much that one poster pointed the Googlers that take part in the discussion (Director level mind you; not the friendly developers and community managers who have been assisting us all these years) to the Chromium Code of Conduct. I am so pissed with this attitude that I forwarded the discussion to Larry Page in a hissy fit… not that I expect him to read and answer, but it had to be done. Remember the original Google Code of Conduct mantra “Don’t be evil”?

MS Windows on Linux: wine and MinGW-w64

 

I came across two separate discussions on LinuxQuestions.org that had a common root cause; a lack of Windows VST support in Carla and missing PE binary support in Wine causing Windows games to fail on Slackware.
They made me think about how I could help fix the core issue, which is that both SlackBuilds.org and Slackware 3rd party repositories (like mine) do not offer MinGW packages or scripts. To address the issue I needed to create a MinGW-w64 package, which is what I did. More on that, further down.

Back to the issue at hand and their common root cause.

Starting with Wine 5.x, the developers added support for compiling wine’s Windows programs and DLLs into Microsoft PE (portable executable) format instead of building them as Linux ELF binaries. This has advantages, one of the more obvious ones adding compatibility with some copy protection schemes in Windows games.
However with wine-5.12 and newer, it appears that the PE binary format is now a requirement for some modern Windows-based games that you can play in Wine on Linux. Diablo III, World of Warcraft and others are mentioned in the relevant bug report.

This meant that I needed to do something if I ever wanted to update my own Slackware package for wine to a newer version than the 5.6 I had in my repository. Apparently to compile binaries into native MS Windows PE format, you need MinGW, the “Minimalist GNU for Windows“. In fact, I needed MinGW-w64 whichs is a fork made in 2007 of the original MinGW which adds 64bit Windows support and a lot of other enhancements, and is actively developed. Since this is not available for Slackware as a package or SlackBuild yet, I needed to come up with my own version.

The LQ thread mentions an OS-agnostic project from developer ‘Tk-Glitch’ called  “(Mostly) Portable GCC/MinGW” which people used successfully to obtain a working MinGW compiler on Slackware. Since I was completely clueless about MinGW I started with that script, and for me indeed it built a MinGW compiler suite with support tools. Alas, the script was only meant for 64bit OS-es and of course it was not a proper SlackBuild script. So I used the project as inspiration (like, I used the script’s flow and logic) to write a SlackBuild script that would also work on 32bit Slackware.
The result is that I now have MinGW-w64 packages in my repository for Slackware-current as well as 14.2 (32bit and 64bit). The package installs a profile script to “/etc/profile.d/” which adds the MinGW binaries to your $PATH environment variable. On 64bit Slackware you will get both the MinGW programs that create 64bit Windows PE binaries (x64_64-w64-ming32-*) and those that create 32bit Windows PE binaries (i686-w64-mingw32-*). While on 32bit Slackware you will get programs that create 32bit Windows PE binaries (i586-w64-mingw32-*).

Having a MinGW-w64 package finally enabled me to compile the newest wine (enhanced with the wine-staging patch set) properly.
Since the MinGW compilers are in the $PATH, the wine-build will automatically use those where needed, no change to the SlackBuild was required. The result is a wine-5.17wine-5.18 package which has grown considerably in size due to the addition of PE binaries. I hope this package will enable you gamers to play your favorite game again.
Note that I have added new dependencies to the wine package for Slackware-current. In order to improve DirectX sound support you need FAudio.  For Direct3D 12 support, wine additionally depends on vkd3d. You’ll have to install those from my repository as well.
Both FAudio and vkd3d fail to compile on Slackware 14.2, due to a lack of Vulkan library support and outdated other libraries such as Gstreamer, so the wine package for Slackware 14.2 was built without them (but it does need OpenAL as a dependency there. This got added to slackware-current as ‘openal-soft’).

And then there was Carla, the subject of that other LQ thread.
Carla is an audio plugin host; it is contained in my Slackware Live DAW project. It supports a lot of plugin formats, like LADSPA, DSSI, LV2, VST2, VST3 and more. It turned out that my Slackware package for Carla did not support Windows VST plugins. VST is mostly used on Windows, VST is a proprietary format from Steinberg which requires a licence from them to create or host a plugin. The VST3 source code is placed under a GPL3 license; however you still need written agreement from Steinberg if you want to distribute a plugin. Nevertheless, if you are a mucisian and purchased a VST plugin then Carla needs some additional work to use that Windows VST plugin.
Again, MinGW-w64 (and wine) were needed to expand the capabilities of my carla package. Luckily, a new version of Carla was released yesterday so I could apply my newfound knowledge immediately. The new carla-2.2.0 package supports Windows VST’s. Go get it.

For the techies:
Note the different architecture used in the names of the MinGW 32bit binary compilers: “i686” on Slackware64 and “i586” on Slackware. On 64bit Slackware I compile a new gcc, binutils and all the libraries they need first, and use them as a bootstrap for compiling MinGW-w64. That is why I could switch away from Slackware’s “i586” to a new “i686” architecture target, and in principle I can use a different version of GCC than the one shipped with Slackware. On the Slackware 32bit OS I was unable to compile this “bootstrap GCC” so I needed to stick to the version of GCC which is present on Slackware and use that to compile MinGW-w64.
If someone feels adventurous and has a lot of free time, the issue on 32bit Slackware is that after I compile various support libraries, then binutils and then gcc, I can not complete the gcc compilation because it ends prematurely with an error “/tmp/build/mingw_gcc_bootstrap/bin/ld: cannot find -lc“. Apparently the linker does not search /lib or /usr/lib for whatever reason. If I add symlinks for libc into “/tmp/build/mingw_gcc_bootstrap/lib/” then I get a little further in the process, but then the same happens for -lm”. Etcetera. I do not have this issue on 64bit Slackware where I use my multilib version of gcc packages… no idea whether that makes the difference. So in 32bit Slackware I just skip compiling my own GCC and move immediately to compiling MinGW. Suggestions are welcome and appreciated.

Have fun with this! Eric

Note: I used one of Dave Gauer’s logos for MinGW-w64 to decorate this blog page.

Configuring Slackware for use as a DAW

Welcome, music-making (Slackware) Linux-using friends. This article will be an interactive work and probably never finished. I am looking for the best possible setup of my Slackware system for making music without having to revert to a custom Linux Distro like the revered StudioWare.
Please supplement my writings with your expert opinions and point out the holes and/or suggest improvements/alternatives to my setup. Good suggestions in the comments section will be incorporated into the main article.
Your contributions and knowledge are welcomed!


What is a DAW?

In simple terms, a Digital Audio Workstation is a device where you create and manipulate digital audio.

Before the era of personal computing, a DAW would be a complex piece of (expensive) hardware which was only within reach of music studios or artists of name and fame. A good example of an early DAW is the Fairlight CMI (Computer Musical Instrument), released in the late 70’s of the previous century. This Fairlight was also one of the first to offer a digital sampler. The picture at the left of this page is its monitor with a light-pen input.

These days, the name “DAW” is often used for the actual software used to produce music, like the free Ardour, LMMS, or the commercial Ableton Live, FL Studio, Cubase, Pro Tools, etcetera.
But “Digital Audio Workstation” also applies to the computer on which this software is running and whose software and hardware is tailored to the task of creating music. To make it easier for musicians who use Linux, you can find a number of custom distributions with a focus on making electronic music, such as StudioWare (Slackware based), AV Linux (Debian based), QStudio64 (Mint based), so that you do not have to spend a lot of time configuring your Operating System and toolkits.

A ready-to-use distro targeting the musician’s workflow is nice, but I am not the average user and want to know what’s going on under the hood. What’s new… And therefore, in the context of this article I am going to dive into the use of a regular Slackware Linux computer as a DAW.

I wrote an earlier article where I focused on the free programs that are available on a Linux platform and for which I created Slackware packages: Explorations into the world of electronic music production.
That article provided a lot of good info (and reader feedback!) about creating music. What lacked, was a good description of how to setup your computer as a capable platform to use all that software on. Slackware Linux out of the box is not setup as a real-time environment where you have low-latency connectivity between your musical hardware and the software. But these capabilities are essential if you want to produce electronic music by capturing the analog signals of physical instruments and converting them to digital audio, or if you want to add layers of CPU intensive post-processing to the soundscape in real-time.
Achieving that will be the topic of the article.


Typical hardware setup


The software you use to create, produce and mix your music… it runs on a computer of course. That computer will benefit from ample RAM and a fast SSD drive. It will have several peripherals connected to it that allow you to unleash your musical creativity:

  • a high-quality sound card or external audio interface with inputs for your physical music instruments and mics, sporting a good Analog to Digital Converter (DAC) and adding the least amount of latency.
  • an input device like a MIDI piano keyboard or controller, or simply a mouse and typing keyboard.
  • a means to listen to the final composite audio signal, i.e. a monitor with a flat frequency response.

In my case, this means:

  • USB Audio Interface: FocusRite Scarlett 2i4 2nd Gen
  • Voice and instrument recording mics connected to the USB audio interface:
    • Rode NT1-A studio microphone with a pop-filter, or
    • Behringer C-2 2 studio condenser microphones (matched pair)
  • MIDI Input: Novation Launchkey 25 MK2 MIDI keyboard
  • Monitor: I use Devine PRO 5000 studio headphones instead of actual studio monitors since i am just sitting in the attic with other people in the house…
  • And a computer running Slackware Linux and all the tools installed which are listed in my previous article.

Configuring Slackware OS


We will focus on tweaking OS parameters in such a way that the OS essentially stays ‘out of your way’ when you are working with digital audio streams. You do not want audio glitches, drop-outs or experience out-of-sync inputs. If you are adding real-time audio synthesis and effects, you do not want to see delays. You do not want your computer to start swapping out to disk and bogging down the system. And so on.

Note that for real-time behavior of your applications, you do not have to install a real-time (rt) kernel!


The ‘audio’ group

The first thing we’ll do is decide that we will tie all the required capabilities to the ‘audio’ group of the OS. If your user is going to use the computer as a DAW, you need to add the user account to the ‘audio’ group:

# gpasswd -a your_user audio

All regular users stay out of that ‘audio’ group as a precaution. The ‘audio’ members will be able to claim resources from the OS that can lock or freeze the computer if misused. Your spouse and kids will still be able to fully use the computer – just not wreck havoc.


The kernel

A Slackware kernel has ‘CONFIG_HZ_1000’ set to allow for a responsive desktop, and ‘CONFIG_PREEMPT_VOLUNTARY’ as a sensible trade-off between having good overall throughput (efficiency) of your system and providing low latency to applications that need it.

So you are probably going to be fine with the stock ‘generic’ kernel in Slackware. One tweak though is going to improve on low-latency. One important part of the ‘rt-kernel’ patch set was added to the Linux source code, and that is related to interrupt handling. Threaded IRQs are meant to minimize the time your system spends with all interrupts disabled. Enabling this feature in the kernel is done on the boot command-line, by adding the word ‘threadirqs’ there.

  • If you use lilo, open “/etc/lilo.conf” in an editor and add “threadirqs” to the value of the “append=” keyword, and re-run ‘lilo’.
  • If you use elilo, open /boot/efi/EFI/Slackware/elilo.conf and add “threadirqs” to the value of the “append = ” keyword
  • If you are using Grub, then open “/etc/default/grub” in an editor and add “threadirqs” to the (probably empty) value for “GRUB_CMDLINE_LINUX_DEFAULT”. Then re-generate your Grub configuration.

CPU Frequency scaling

Your Slackware computer is configured by default to use the “ondemand” CPU frequency scaling governor. The kernel will reduce the CPU clock frequency (modern CPU’s support this) if the system is not under high load, to conserve energy. However, much of the load in a real-time audio system is on the DSP, not on the CPU, and the scaling governor will not catch that. It could result in buffer underruns (also called XRUNs). Therefore, it is advised to switch to the “performance” governor instead which will always keep your CPU cores at max clock frequency. To achieve this, open the file “/etc/default/cpufreq” in an editor and add this line (make sure that all other lines are commented out with a ‘#” at the beginnning!):

SCALING_GOVERNOR=performance

After reboot, this modification will be effective.

Note: if you want to use your laptop as a DAW, you may want to re-consider this modification. You do not want to have your CPU’s running at full clockspeed all of the time, it eats your battery life. Make use of this “performance” feature only when you need it.


Real-time scheduling

Your DAW and the software you use to create electronic music, must always be able to carry out their task irrespective of other tasks your OS or your Desktop Environment want to slip in. This means, your audio applications must be able to request (and get) real-time scheduling capabilities from the kernel.

How you do this depends on whether your Slackware uses PAM, or not.

If PAM is installed, RT Scheduling and the ability to claim Locked Memory is configured by creating a file in the “/etc/security/limits.d/” directory – let’s name the file “/etc/security/limits.d/rt_audio.conf” (the name is not relevant, as long as it ends on ‘.conf’) and add the following lines.

# Real-Time Priority allowed for user in the 'audio' group:
# Use 'unlimited' with care,a misbehaving application can
# lock up your system. Try reserving half your physical memory:
#@audio - memlock 2097152
@audio - memlock unlimited
@audio - rtprio 95

If PAM is not part of your system, we use a feature which is not so widely known to achieve almost the same thing: initscript (man 5 initscript). When the shell script “/etc/initscript” is present and executable, the ‘init’ process will use it to execute the commands from inittab. This script can be used to set things like ulimit and umask default values for every process.
So, let’s create that file “/etc/initscript”, add the following block of code to it:

# Set umask to safe level:
umask 022
# Disable core dumps:
ulimit -c 0
# Allow unlimited size to be locked into memory:
ulimit -l unlimited
# Address issue of jackd failing to start with realtime scheduling:
ulimit -r 95
# Execute the program.
eval exec "$4"

And make it executable:

# chmod +x /etc/initscript

The ulimit and umask values that have been configured in this script will now apply to every program started by every user of your computer. Not just members of the ‘audio’ group. You are warned. Watch your kids.


Use sysctl tweaks to favor real-time behavior

The ‘sysctl’ program is used to modify kernel parameters at runtime. We need it in a moment, but first some preparations.
A DAW which relies on ALSA MIDI, benefits from access to the high precision event timer (HPET). We will allow the members of the ‘audio’ group to access the HPET and real-time clock (RTC) which by default are only accessible to root.
We achieve this by creating a new UDEV rule file “/etc/udev/rules.d/40-timer-permissions.rules”. Add the following lines to the file and then reboot to make your changes effective:

KERNEL=="rtc0", GROUP="audio"
KERNEL=="hpet", GROUP="audio"

With access to the HPET arranged, we can create a sysctl configuration file which the kernel will use on booting up. There are a number of audio related ‘sysctl‘ settings that allow for better real-time performance, and we add these settings to a new file “/etc/sysctl.d/daw.conf”. Add the following lines to it:

dev.hpet.max-user-freq = 3072
fs.inotify.max_user_watches = 524288
vm.swappiness = 10

The first line allows the user to access the timers at a higher frequency than the default ’64’. Note that the max possible value is 8192 but a sensible minimum for achieving lower latency is 1024. The second line is suggested by the ‘realtimeconfigquickscan‘ tool, and increases the maximum number of files that the kernel can track on behalf of the programs you are using (no proof that  this actually improves real-time behavior). And the third line will prevent your system from starting to swap too early (its default value is ’60’) which is a likely cause for XRUNs.


Disable scheduled tasks of the OS and your DE

The suggestions above are mostly kernel related, but your own OS and more specifically, the Desktop Environment you are using can get in the way of real-time behavior you want for your audio applications.

General advice:

  • Disable your desktop’s Compositor (KWin in KDE Desktop, Compiz on XFCE and Gnome Desktop). Compositing requires a good GPU supporting OpenGL hardware acceleration but still this will put a load on your CPU and in particular on the application windows.

Desktop-specific:

  • Plasma 5 Desktop
    • The most obvious candidate to mess with your music making process is Baloo, the file indexer. The first time Baloo is started on a new installation, it will seriously bog down your computer and eat most of its CPU cycles while it works its way through your files.
      If you really want to keep using Baloo (it allows for a comfortable file search in Plasma5) you could at least disable file content indexing and merely let it index the filenames (similar to console-based ‘locate’).
      Go to “System Settings > Workspace > Search > File search” and un-check “also index file content”
      If you want to completely disable Baloo so that you can not re-enable it anymore with any command or tool, do a manual edit of ${HOME}/.config/baloofilerc and make sure that the “[Basic Settings]” section contains the following line:
      Indexing-Enabled=false
    • In KDE, the Akonadi framework is responsible for providing applications with a centralized database to store, index and retrieve the user’s personal information including the user’s emails, contacts, calendars, events, journals, alarms, notes, etc. The alerts this framework generates can interfere with real-time audio recording, so you can disable Akonadi if you want by running “akonadictl stop” in a terminal, under your own user account. Then make sure that your desktop does not auto-start applications which use Akonadi, Also, open the configuration of your desktop Clock and uncheck “show events” to prevent a call into Akonadi.
      Read more on https://userbase.kde.org/Akonadi/nl#Disabling_the_Akonadi_subsystem
    • Compositing is another possible resource hog, especially when your computer is in the middle-or lower range. You can easily toggle (disable/re-enable) the desktop compositor by pressing the “Shift-Alt-F12” key combo.
      Note that if you use Latte-dock as your application starter, this will not like the absence of a Compositor. You’ll have to switch back to KDE Plasma’s standard menus to start your applications.

 


Selecting your audio interface

You may not always have your high-quality USB audio interface connected to your computer. When the computer boots, ALSA will decide for itself which device will be your default audio device and usually it will be your internal on-board sound card.

You can inspect your computer’s audio devices that ALSA knows about. For instance, my computer has onboard audio, then the HDMI connector on the Nvidia GPU provides audio-out; I have a FocusRite Scarlett 2i4, an old Philips Web Cam with an onboard microphone and I have loaded the audio loopback module. That makes 5 audio devices, numbered by the kernel from 0 to 4 with the lowest number being the default card:

$ cat /proc/asound/cards 
0 [NVidia_1    ]: HDA-Intel - HDA NVidia
                  HDA NVidia at 0xdeef4000 irq 22
1 [NVidia      ]: HDA-Intel - HDA NVidia
                  HDA NVidia at 0xdef7c000 irq 19
2 [USB         ]: USB-Audio - Scarlett 2i4 USB
                  Focusrite Scarlett 2i4 USB at usb-0000:00:02.1-2, high speed
3 [U0x4710x311 ]: USB-Audio - USB Device 0x471:0x311
                  USB Device 0x471:0x311 at usb-0000:00:02.0-3, full speed
4 [Loopback ]: Loopback - Loopback
               Loopback 1

Note that these cards can be identified when using ALSA commands and configurations, both by their hardware index (hw0, hw2) and by their ‘friendly name‘ (‘Nvidia_1’, ‘USB’).

Once you know which cards are present, you can inspect which kernel modules are loaded for these cards – The same indices as shown in the previous ‘cat /proc/asound/cards‘ command are also listed in the output of the next command:

$ cat /proc/asound/modules
0 snd_hda_intel
1 snd_hda_intel
2 snd_usb_audio
3 snd_usb_audio
4 snd_aloop

You’ll notice that some cards use the same kernel module. If you want to deterministically number your sound devices instead allowing the kernel to probe and enumerate your hardware, you’ll have to perform some wizardry in the /etc/modprobe.d/ directory.

Using pulseaudio you can change the default audio output device on the fly.
First you determine the naming of devices in pulseaudio (it’s quite different from what you saw in ALSA) with the following command which lists the available outputs (called sinks by pulseaudio):

$ pactl list short sinks
0 alsa_output.usb-Focusrite_Scarlett_2i4_USB-00.analog-surround-40 module-alsa-card.c s32le 4ch 48000Hz SUSPENDED
1 alsa_output.pci-0000_00_05.0.analog-stereo module-alsa-card.c s32le 2ch 48000Hz SUSPENDED
3 alsa_output.platform-snd_aloop.0.analog-stereo module-alsa-card.c s32le 2ch 48000Hz SUSPENDED
4 jack_out module-jack-sink.c float32le 2ch 48000Hz RUNNING
11 alsa_output.pci-0000_02_00.1.hdmi-stereo-extra1 module-alsa-card.c s32le 2ch 48000Hz SUSPENDED

You see which device is the default because that will be the only one that is in ‘RUNNING’ state and not ‘SUSPENDED’. Subsequently you can change the default output device, for instance to the FocusRite interface:

$ pactl set-default-sink alsa_output.usb-Focusrite_Scarlett_2i4_USB-00.analog-surround-40

You can use these commands to help you deciding which to use as your default device if you un-plug your USB audio interface, or if you want to let your system sounds be handled by an on-board card while you are working on a musical production using your high-quality USB audio interface – each device with their own set of speakers.


Connecting the dots: ALSA -> Pulseaudio -> Jack

The connecting element in all the software tools of your DAW is the Jack Audio Connection Kit, or Jack for short. Jack is a sound server – it provides the software infrastructure for audio applications to communicate with each other and with your audio hardware. All my DAW-related software packages have been compiled against the Jack libraries and thus can make use of the Jack infrastructure once Jack daemon is started.

Once Jack takes control, it talks directly to ALSA sound system.

Slackware uses the ALSA sound architecture since replacing the old OSS (open sound system) with it, many years ago. ALSA is the kernel-level interface to your audio hardware combined with a set of user-land libraries and binaries to allow your applications to use your audio hardware.
Pulseaudio is a software layer which was added to Slackware 14.2. Basically it is a sound server (similar to Jack) which interfaces between ALSA and your audio applications, providing mixing and re-sampling capabilities that expand on what ALSA already provides. It deals with dynamic adding and removing of audio hardware (like head-phones) and can transfer audio streams over the network to other Pulseaudio servers.
Musicians and audiophiles sometimes complain that Pulseaudio interferes with the quality of the audio. Mostly this is caused by the resampling that Pulseaudio may do when combining different audio streams but this can be avoided by configuring your system components to all use a single sample rate like 44,1 or 48 KHz. Also, in recent years the quality of the Pulseaudio software has improved quite a bit.

When Jack starts it will interface directly to ALSA, bypassing Pulseaudio entirely. What that means is that all your other applications that are not Jack-aware suddenly stop emitting sound because they still play via Pulseaudio. Luckily, we can fix that easily, and without using any custom scripting.

All it takes is the Jack module for Pulseaudio. The source code for this module is part of Pulseaudio but it is not compiled and installed in Slackware since Slackware does not contain Jack. So what I did is create a package which compiles just that Pulseaudio Jack module. You should install my “pulseaudio-jack” package from my repository. The module contains a library responsible for detecting when jack starts and then enables ‘source’ and ‘sink’ for Pulseaudio-aware applications to use.

The main pulseaudio configuration file “/etc/pulse/default.pa” already contains the necessary lines to support the pulseaudio-jack module:

### Automatically connect sink and source if JACK server is present
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif

The only thing you need to do is ensuring that jackdbus is started. If you use qjackctl to launch Jack, you need to check the “Enable D-Bus interface” and “Enable JACK D-Bus interface” boxes in “Setup -> Misc”. See next section for more details on using QJackCtl.

In 2020 this is all it takes to route all output from your ALSA and Pulseaudio applications through Jack.


Easy configuration of Jack through QJackCtl

The Jack daemon can be started and configured all from the commandline and through scripts. But when your graphical DAW software runs inside a modern Desktop Environment like XFCE or KDE Plasma5, why not take advantage of graphical utilities to control the Jack sound server?

DAW-centric distros will typically ship with the Cadence Tools, which is a set of Qt5 based applications written for the KXStudio project (consisting of Cadence itself and also Catarina, Catia and Claudia) to manage your Jack audio configuration easily. Note that I have not created packages for Cadence Tools but if there’s enough demand I will certainly consider it, since this toolkit should work just fine in Slackware:

For a Qt5 based Desktop Environment like KDE Plasma5, a control application like QJackCtl will blend in just as well. While it’s more simplistic than Cadence, it does a real good job nevertheless. Its author offers several other very nice audio programs at https://www.rncbc.org/ like QSampler and the Vee One Suite of old-skool synths.

Like Cadence, QJackCtl offers a graphical user interface to connect your audio inputs and outputs, allowing you to create any setup you can imagine:

QJackCtl can be configured to run the Jack daemon on startup and enable Jack’s Dbus interface. Stuff like defining the samplerate, the audio device to use, the latency you allow, etcetera is also available. And if you tell the Desktop Session Manager to autostart qjackctl when you login, you will always have Jack ready and waiting for you.

 


Turning theory into practice

The reason for writing up this article was informational of course, since this kind of comprehensive detail is not readily available for Slackware. With all the directions shared above you should now be able to tune your computer to make it suited for some good music recording and production, and possibly live performances.

A secondary goal of the research into the article’s content was to gain a better understanding of how to put together my own Slackware based DAW Live OS. All of the above knowledge is being put into the liveslak scripts and Slackware Live Edition now has a new variant next to PLASMA5, SLACKWARE, XFCE, etc… it is “DAW“.
I am posting ISO images of this Slackware Live DAW Edition to https://martin.alienbase.nl/mirrors/slackware-live/pilot/ and hope some of you find it an interesting enough concept that you want to try it out.

Note that you’ll get a ~ 2.5 GB ISO which boots into a barebones KDE Plasma5 Desktop with all my DAW tools present and Jack configured, up and running. User accounts are the same as with any Slackware Live Edition: users ‘live‘ and ‘root‘ with passwords respectively ‘live‘ and ‘root‘.

Why KDE Plasma5 as the Desktop of choice? Isn’t this way too heavy on resources to provide a low-latency workflow with real-time behaviour?
Well actually… the resource usage and responsiveness of KDE Plasma5 is on par or even better than the light-weight XFCE. Which is the reason why an established distro like Ubuntu Studio is migrating from XFCE to KDE Plasma5 for their next release (based on Ubuntu 20.10) and KXStudio targets the KDE Plasma5 Desktop as well.

You can burn the ISO to a DVD and then use it as a real ‘live’ OS which is fresh and pristine on every boot, or use the ‘iso2usb.sh’ script which is part of liveslak to copy the content of the ISO to a USB stick – which adds persistency, application state saving and additional storage capability. The USB option also allows you to set new defaults for such things as language, keyboard layout, timezone etc so that you do not have to select those everytime through the bootmenus.

If your computer has sufficient RAM (say, 8 GB or more), you should consider loading the whole Live OS into RAM (using the ‘toram’ boot parameter) and have a lightning-fast DAW as a result. My tests with a USB stick with USB-3 interface was that it takes 2 to 3 minutes to load the 2.5 GB into RAM, which compares to nothing if your DAW session will be running for hours.


Shout out

A big help was the information in the Linux Audio Wiki, particularly this page: https://wiki.linuxaudio.org/wiki/system_configuration. In fact, I recommend that you absorb all of the information there.
On that page, you will also find a link to a Perl program “realtimeconfigquickscan” which can scan your system and report on the readiness of your computer for becoming a Digital Audio Workstation.

Good luck! Eric