My thoughts on Slackware, life and everything

Tag: ardour

Ardour 7.0, Avidemux 2.8.1 and more cool stuff added to my repositories

A month full of interesting package updates in my Slackware package repositories. I have not blogged about them, because of a busy work schedule, but here are the highlights.
Note that you can subscribe your feedreader to my RSS feeds (regular and restricted) so that you never miss a package update!

Ardour

With more than two years of development after 6.0 was released in May 2020, a new major update for Ardour was finally made available last week. Packages are available for 32bit and 64bit Slackware 15.0 and -current.
Ardour 7.0 comes with lots of new features, and Unfa goes in-depth in this YouTube video:

Avidemux

Avidemux 2.8.1 was released in September, and I missed the announcement. Fortunately I was alerted to it today by a Slackware user who commented on the blog. These packages are found in my restricted repository because they contain AAC encoder libraries, the code for which is patent-encumbered in the United States.

For the 32bit package I had to forcibly disable SSE support in the soundtouch library, if anyone comes across a patch that fixes the compilation error, let me know. I guess nobody runs test builds of Avidemux on a 32bit OS anymore.

Chromium

I uploaded three consecutive updates for Chromium 106 (regular as well as un-googled) during the last month, did anyone notice?
As usual, any update to Chromium is a must-do, to eradicate any vulnerabilities that allow online hackers to own your computer. Again, subscribing to my repository’s RSS feed will alert you to updates immediately.

Docker

My four Docker related packages (runc, containerd, docker and docker-compose, you don’t need any other package) were also updated to their latest releases last week.
A note: I provide 32bit packages for Docker, even though that is supposed to not work. At least, it is not supported by the developers. I wonder, since I tested the 32bit packages and they actually do work (I can run 32bit containers on a 32bit host) is there anyone who uses these? Or should I skip 32bit builds of future Docker releases altogether? Let me know.

LibreOffice

LibreOffice 7.4.2 was released last week and I uploaded a set of packages right before the weekend, so that you can enjoy the latest and greatest of this office suite on Slackware 15.0 and -current.

Note that I build these packages on Slackware 15.0 but also offer these same packages for installation on slackware-current. Since slackware-current ships newer (incompatible) versions of boost and icu4c, please also install boost-compat and icu4c-compat from my repository – these packages contain older versions of the boost and icu4c libraries and are a live-saver if you are running slackware-current. Note that this “compat” is not the same as “compat32” – which is the designation for the converted 32bit Slackware packages in my multilib package set!

OBS Studio

If you ever have a need for recording a live video using professional-grade software, Open Broadcaster Software released OBS Studio version 28.0.3 recently. If you want to broadcast a live stream of an event you are covering, OBS Studio plugs straight into Youtube, Facebook, Twitch or other streaming platforms. Packages are available for Slackware 15.0 and -current.

More…

Also I had to update Calibre, FFMpeg and Audacity packages for Slackware-current, after the recent incompatible upgrades of Qt5 and FFMpeg in the OS.
If you wonder ‘why ffmpeg, it’s part of Slackware already‘ – my ffmpeg package has several codecs enabled that the stock Slackware version does not offer, particularly the package in my restricted repository.

Have fun! Eric

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

Explorations into the world of electronic music production

Apart from playing the recorder flute in primary school and keyboard with my father-in-law, I pretty much never had the chance to make music or even, to create new music. That did not bother me in the past, but when I married into a very musical and creative family I realized I was the only one without musical education or skill in playing an instrument. The family has (ir)regular jam sessions and sometimes arranges (mostly private but) quite high-quality classical music performances.

But, I had other hobbies, Slackware being one of them of course, and reading books while listening to my own music collection (which almost has no overlap with my wife’s by the way). And I was glad when I saw that my son has inherited my wife’s genes and has a knack for languages and music. He is exploring digital music making, has a keyboard or two and installed Ableton Live on his computer. I could never convince him that Slackware was the better alternative to Windows, all his friends are on Windows and what the group does is important for a teen. And furthermore, there’s a slew on tutorial and instruction video’s out there, all expecting you to use Ableton.

I looked at Ableton for its possibilities, and I had several discussions with one of my colleague/friends who is also a DJ/producer and uses Ableton a his primary driver. Seems to be a real nice program… but it costs hundreds of euros. So purchasing a license for Windows 10 and another one for Ableton, just to be able to converse with my son was not an option. I’ll introduce him to my friend and we’ll visit his studio to get inspiration. Then he can implement what he learnt, using tools he is familiar with.

During the past two years, I made some purchases just to have fun with creating sounds and rhythms, buying a couple of Pocket Operators from Teenage Engineering. I had one of these PO’s in my car, plugged into the car stereo and let my son create loops and sounds while on trips. Lots of fun and not too expensive. I also have an external USB soundcard,a FocusRite Scarlett 2i4. and a MIDI keyboard and bass guitar in the attic. But life’s too short and lots of stuff asks for attention – I never spent much productive time with my gear.

But these recent discussions about how to create digital music from scratch, and my wish toe be able to record the live performances of my in-laws, triggered a desire to have a better look at electronic music production and music recording, but then on Slackware Linux of course.

What would be needed for that? I would need software to create sounds (i.e. synthesizers), manipulate audio, create drum tracks, sequence the music, record and mix it. Also my USB sound card needs to be supported and I want my use midi keyboard to enter the notes that I play into the system. I obviously need low-latency real-time performance of my Digital Audio Workstation (DAW).

I guess that for many Linux musicians, the Debian-based AVLinux is a first choice when looking for pre-packaged, pre-configured Digital Audio Workstation (DAW) solutions and supporting software. But we Slackers already have Studioware – a Slackware expansion set which gives you a great toolkit with audio- and video manipulation software. My liveslak project even supports Studioware directly, and is able to create a Studioware Live ISO. You should try that out – it has a ton of software, not just for audio but also for video recording, manipulation and recording.

But… again… and that’s just me… I think that there’s no fun in using other people’s ready-made stuff. Here I am thinking again as the software packaging geek who wants to create possibilities for other people while not necessarily using those myself.

Anyway, I decided not to look too closely at what others had already done, and research a decent set of software products that I want to try out, and on Slackware-current too. Studioware is running on Slackware 14.2 and I tend to develop new stuff on our development platform.

And after a couple of weeks spent on reading, compiling, testing and scratching my head at my lack of knowledge, I came up with this list of software that I think is a nice start for venturing into DAW country. All of this is free and open source:

  • Music recording/mixing/manipulating:
    • ardour: the professional-grade Digital Audio Workstation (DAW).
  • Sound editing:
    • audacity: a graphical sound editor with a GTK3 based UI.
  • Synthesizers:
    • amsynth: an analog modelling synthesizer.
    • helm: a polyphonic synth with lots of modulation also works as a LV2 plugin.
    • zynaddsubfx: a software synthesizer and also a LV2 plugin.
  • Drum machine:
    • hydrogen: an advanced drum machine with Qt5 based GUI.
  • MIDI input:
    • vmpk: Virtual MIDI Piano Keyboard is a MIDI events generator and receiver which can be used to drive a MIDI synthesizer.
  • Audio manipulation plugins (not counting the standalone applications mentioned above that will also run as an Ardour plugin):
    • avldrums.lv2: a LV2 plugin wrapping the AVLinux Drumkits.
    • calf: Calf Studio Gear is a LV2/DSSI plugin collection but it also works as a standalone JACK-host.
    • eq10q: equalizer (and more) as LV2-plugins.
    • vamp-aubio-plugins: a small collection of audio feature extraction plugins.
  • System tools:
    • jack-audio-connection-kit (jack2): to provide low-latency real-time audio routing.
    • alsa-plugins-jack: part of alsa-plugins but not included in Slackware, allows audio to be routed to and from ALSA applications that are not JACK-aware.
    • qjackctl: a Qt5 application to control the JACK sound server.
  • Support libraries for implementing a DAW:
    • aubio: a system to extract annotations from audio signals.
    • ladspa_sdk:  SDK for sound plugins adhering to the Linux Audio Developer’s Simple Plugin API (LADSPA).
    • liblo: implementation of the Open Sound Control (OSC), a protocol for communication among multimedia devices.
    • lv2: the LV2 open standard for audio plugins.
    • rubberband: a library for audio time-stretching and pitch-shifting.
    • vamp-plugin-sdk: an audio processing plugin system (you still need to install actual plugins).
    • wxGTK3: GTK+3 implementation of the cross-platform wxWidgets API
  • Further dependencies for the above (not part of Slackware) that I had to create as packages to get it all working:
    • drumstick: MIDI libraries for Qt5. This is also part of my ‘ktown‘ Plasma5 desktop package set.
    • liblrdf: library to access LADSPA plugin metadata.
    • lilv: a library for using LV2 plugins in applications.
    • mxml: library to read and write XML and XML-like data files.
    • serd: RDF syntax library.
    • sord: library for storing RDF data in memory.
    • sratom: library for serialising LV2 atoms to and from RDF.
    • suil: library for loading and wrapping LV2 plugin UIs.
  • System libraries that I already had in my repositories and which you may already have installed and which are now all available in Slackware’s core distro:
    • qt5: the toolkit for creating graphical interfaces
    • libxkbcommon: support library for Qt5, handling keyboard descriptions.
    • OpenAL: support library for Qt5, implementing a 3D audio API.
    • SDL_sound: support library for Qt5 handling the decoding of various sound file formats.
Update 15-march-2019

Additions to the above set resulting from the discussion in the comments area below the main article:

  • Music notation:
  • Live Coding:
    • supercollider: a platform for audio synthesis and algorithmic composition
  • Plugins:
    • lsp-plugins: Linux Studio Plugins supporting LV2, LADSPA and Jack.
  • Support libraries:
    • portaudio: a cross platform audio I/O library.
    • portmidi: a platform independent library for MIDI I/O.
  • Front-ends:
    • qsynth: a Qt5 GUI Interface for FluidSynth.
Update 20-january-2020
  • System tools:
  • Support libraries:
    • dssi: an API for audio processing plugins.
    • libgig: a library for loading, modifying and creating gigasampler files.
    • liblscp: the LinuxSampler Control Protocol library.
  • Synthesizers:
  • Front-ends:
    • qsampler: a LinuxSampler Qt5-based user interface.
Update 27-january-2020
  • Support libraries:
  • Audio file analysis:
  • Synthesizers:
    • zyn-fusion: this is the zynaddsubfx realtime synthesizer (see above), but now with a new GUI based on ruby-zest.
      Install either the zynaddsubfx package (with the ntk GUI) or the zyn-fusion package (with the zest GUI) but not both.
Update 2-february-2020
  • Support libraries:
    • OpenBLAS: an optimized BLAS library. The package contains BLAS, CBLAS, LAPACK and LAPACKE support.
    • python-numpy: a python module for scientific computing.
    • python-pathlib2: a backport of pathlib to fully support stdlib Python API.
    • python-pyo: a Python module for digital signal processing.
    • wxpython: a cross-platform GUI toolkit.
  • Synthesizers:
    • cecilia5: an audio signal processing tool for sound designers.
Update 10-june-2020
  • Support libraries:
    • libsass: the C/C++ implementation of a Sass compiler.
    • sassc: the C implementation of Sass CSS preprocessor.
  • Music recording/mixing/manipulating:
    • non-daw: ‘Non’ DAW studio, with low hardware needs and responsive enough to be used live.
    • guitarix: a virtual guitar amplifier and effects rack.
Update 28-june-2020
  • Support libraries:
  • System tools:
    • cadence tools: JACK toolbox for audio production, an alternative to qjackctl.
    • jack_capture: a program for recording sound files with JACK.
    • meterbridge: meters for the JACK audio server.
    • zita-ajbridge: a JACK client to use additional ALSA devices.
Update 29-june-2020
  • Support libraries:
    • chromaprint: an audio fingerprint library.
    • faad2: ISO AAC decoder library.
    • hidapi: a library to communicate with USB & Bluetooth HID devices.
    • libmodplug: a MOD playing library.
    • libmp4v2: a library to read, create, and modify mp4 files.
    • protobuf: Google’s data interchange format.
    • qtkeychain: Qt API to store passwords and other secret data securely.
  • DJ Software:
    • mixxx: powerful DJ and performance software.
Update 30-june-2020
  • Support libraries:
  • System tools:
    • carla: a fully-featured audio plugin host.
Update 23-july-2020
  • Live Coding:
    • sonic-pi: a popular live-coding music performance tool.
Update 04-august-2020
  • Audio manipulation plugins:
    • gxplugins.lv2: a set of additional LV2 plugins for Guitarix.
    • x42-plugins: a set of LV2 plugins with standalone JACK applications.
  • Support libraries:
    • libltc: a Linear/Longitudinal Time Code (LTC) library.
    • zita-convolver: a real-time convolution matrix for up to 64 audio inputs and outputs.
Update 01-september-2020
  • Music recording/mixing/manipulating:
    • jamulus: internet jam session software (client & server).
Update 06-september-2020
  • Music recording/mixing/manipulating:
    • muse: a midi and audio sequencer.
  • Support libraries:
    • rtaudio: provides a common API for realtime
      audio I/O.
    • rtmidi: provides a common API for realtime
      MIDI I/O.
Update 20-september-2020
  • Music recording/mixing/manipulating:
    • qmidiarp: a MIDI arpeggiator, sequencer and LFO.
    • qtractor: an audio/MIDI multitrack sequencer.
Update 11-october-2020
  • Music recording/mixing/manipulating:
    • giada: a minimalist and hardcore music production tool.
Update 16-december-2020
  • Music recording/mixing/manipulating:
    • zrythm: a highly automated and intuitive digital audio workstation.
Update 20-december-2020
  • Support libraries:
    • libmicrohttpd: a small C library to make it easy to run a HTTP server as part of another application.
  • System tools:
    • faust: a functional programming language for real-time sound synthesis and audio processing.
Update 25-december-2020
Update 16-june-2021
  • Support libraries:
    • dblatex: DocBook to LaTeX/ConTeXt Publishing.
    • guile1.8: an interpreter for Scheme language.
  • Audio manipulation plugins:
  • Music notation:
  • Music recording/mixing/manipulating:
    • rosegarden: MIDI/audio sequencer and notation editor.
Update 26-june-2021
Update 10-july-2021
  • Support libraries:
    • libsmf: a standard MIDI fileformat library.
  • Drum kit:
    • dgedit: the drumgizmo drumkit editor.
    • drumgizmo: multichannel, multilayered drum plugin and stand-alone application.
Update 03-september-2021
  • Synthesizers:
    • VCV Rack modules: countmodula, mental, mindmeldmodular, modularfungi, packone, studiosixplusone, squinkyvcv, valley.
Update 03-september-2022
Update 15-june-2023
  • Synthesizer:
    • surge-xt: a powerful subtractive hybrid synthesizer.

Looking back, that is a big list! Actually when I started with my shortlist as mentioned above I did not anticipate that my ideas would require this many tools to support it. However I think that in order to do some serious audio production work on your computer, this is actually the minimum of applications that you require. There may be more, and I am very curious to hear from you if there is Open Source Software not on the above list, which you think is invaluable to your work as a musician or music producer and should be added here.

The ‘big boy’ in this collection, and the center of any DAW activities on Linux, is Ardour.

Ardour DAW

This is a complex program, but luckily the developers have an extensive manual online. And if you search on Youtube you will find a lot of videos on how to work in Ardour (most of them for older versions and most of them too obscure or too rambling to be educational). However, an Ardour channel on Youtube has just been created with the intention of releasing a new series of quality instruction videos, produced by Unfa who himself has a lot of nice videos on his own channel. Like I said, I have been scratching my head a lot lately, but my hair is still there and I will make progress and understand how to use this tool efficiently… eventually.
And I am glad to finally have Audacity in my repository, something I wanted/needed for quite a while.

All these packages are available in my regular repository, with one caveat (at least for now): I have built all of them for Slackware-current (both 32bit and 64bit). If you are running Slackware 14.2 then for now you need to have a good look at Studioware instead, or you can of course download the sources for my packages and compile them yourself.
The build order is roughly like this:

  • jack2
  • alsa-plugins-jack (depends on jack2)
  • pulseaudio-jack (Depends on jack2)
  • lv2
  • vamp-plugin-sdk
  • aubio (depends on jack2, and additionally on ffmpeg on Slackware 14.2)
  • liblo
  • ladspa_sdk
  • liblrdf (depends on ladspa_sdk)
  • rubberband (depends on ladspa_sdk and vamp-plugin-sdk)
  • serd
  • sord (depends on serd)
  • sratom (depends on lv2 and sord)
  • lilv (depends on sratom)
  • suil (depends on lv2 and qt5)
  • soundtouch
  • ardour (depends on jack2 aubio lv2 vamp-plugin-sdk liblo liblrdf lilv rubberband and suil)
  • mxml
  • ntk
  • portmidi (depends on openjre)
  • portaudio (depends on jack2)
  • zynaddsubfx (depends on jack2 liblo mxml ntk and portaudio)
  • hydrogen (depends on jack2 ladspa_sdk liblo liblrdf rubberband and qt5)
  • wxGTK3
  • soxr
  • audacity (depends on jack2 ladspa_sdk lilv soxr suil vamp-plugin-sdk and wxGTK3)
  • qjackctl (depends on jack2 portaudio and qt5)
  • calf (depends on jack2 and lv2, and for Slackware 14.2 additionally on fluidsynth)
  • avldrums.lv2 (depends on lv2)
  • helm (depends on jack2 and lv2)
  • amsynth (depends on jack2 ladspa_sdk and liblo)
  • eq10q (depends on lv2)
  • vamp-aubio-plugins (depends on aubio and vamp-plugin-sdk)
  • drumstick (depends on qt5)
  • vmpk (depends on drumstick)
  • musescore (depends on jack2 portaudio portmidi and qt5)
  • qsynth (depends on qt5)
  • lsp-plugins (depends on jack2 ladspa and lv2)
  • supercollider (depends on jack2 and qt5)
  • dssi (depends on jack2 liblo and ladspa_sdk)
  • libgig
  • liblscp
  • linuxsampler (depends on dssi libgig jack2 ladspa_sdk and lv2)
  • qsampler (depends on libgig liblscp linuxsampler and qt5)
  • libfishsound
  • capnproto
  • sonic-visualiser (depends on capnproto libfishsound liblo liblrdf portaudio rubberband serd sord and qt5)
  • zyn-fusion (depends on dssi jack2 liblo mxml and portaudio)
  • OpenBLAS
  • python-numpy (depends on OpenBLAS)
  • python-pathlib2
  • python-pyo (depends on portaudio portmidi liblo and jack2)
  • wxpython (depends on python-pathlib2 and wxGTK3)
  • cecilia5 (depends on python-numpy python-pyo and wxpython)
  • libsass
  • sassc (depends on libsass)
  • guitarix (depends on faust jack2 ladspa_sdk liblrdf lilv lv2 and sassc)
  • non-daw (depends on jack2 ladspa_sdk liblo liblrdf and ntk)
  • meterbridge
  • jack_capture (depends on jack2, liblo and meterbridge)
  • zita-alsa-pcmi
  • zita-alsa-pcmi
  • zita-ajbridge (depends on jack2 zita-alsa-pcmi and zita-resampler)
  • cadence (depends on a2jmidid jack2 jack_connect pulseaudio-jack and zita-ajbridge)
  • chromaprint
  • libmodplug
  • libmp4v2
  • faad2
  • hidapi
  • protobuf
  • qtkeychain
  • mixxx (depends on chromaprint faad2 hidapi libmodplug libmp4v2 lilv lv2 portmidi portaudio protobuf qtkeychain rubberband and vamp-plugin-sdk)
  • python-pyliblo (depends on liblo)
  • carla (depends on jack2 liblo and python-pyliblo)
  • sonic-pi (build-time dependency on erlang-otp)
  • libltc
  • zita-convolver
  • gxplugins.lv2 (depends on jack2 and lv2)
  • x42-plugins (depends on jack2 liblo libltc lv2 and zita-convolver)
  • jamulus (depends on jack2)
  • rtaudio (depends on jack2)
  • rtmidi (depends on jack2)
  • muse (depends on dssi jack2 ladspa_sdk liblo liblrdf lilv lv2 rtaudio rubberband and sord)
  • qtractor (depends on aubio dssi jack2 ladspa_sdk liblo lilv lv2 rubberband suil and vamp-plugin-sdk)
  • qmidiarp (depends on jack2 liblo and lv2)
  • giada (depends on fltk jack2 and rtmidi)
  • libmicrohttpd
  • faust (depends on libmicrohttpd portaudio rtaudio and supercollider)
  • libsass
  • sassc (depends on libsass)
  • guitarix (depends on faust jack2 ladspa_sdk liblrdf lilv lv2 and sassc)
  • glfw
  • jq
  • vcvrack (depends on glfw jack2 jq rtaudio and rtmidi)
  • noise-repellent (depends on lv2)
  • dblatex
  • guile1.8
  • lilypond (depends on dblatex guile1.8 (and build-time also on fontforge))
  • rosegarden (depends on dssi jack2 ldaspa_sdk liblo liblrdf lilypond)
  • python-ly
  • python-poppler-qt5
  • python-pygame (depends on portmidi)
  • qpageview
  • frescobaldi (depends on lilypond  python-ly  python-poppler-qt5  python-pygame qpageview)
  • libsmf
  • drumgizmo (depends on jack2, libsmf, lv2, zita-resampler)
  • dgedit
  • jack-example-tools (depends on jack2 zita-alsa-pcmi zita-resampler)
  • surge-xt (depends on jack2 and lv2)

I hope to get some interesting feedback from you. I am also considering how all of this could be added to a function-focused liveslak variant, as small as possible so it may load completely into memory. Actually I would prefer to attempt such a Live ISO using a bare Plasma5, rather than XFCE or other light-weight desktop environments (everybody else is probably already using XFCE). The Plasma5 desktop framework is very powerful and fast, and it could benefit the user of a DAW if everything she plugs in just works.
Update 29-jun-2020:
I wrote an article on configuring your Slackware system for using it as a DAW, and also in that article I am presenting a new liveslak variant “DAW” which will generate an ISO of 2.7 GB in size which runs out of the box as a fully configured Slackware Plasma5 based DAW: https://alien.slackbook.org/blog/configuring-slackware-for-use-as-a-daw/

Easy installation

If you use the slackpkg+ extension for slackpkg to manage packages from 3rd-party repositories, then installing all these packages (or refreshing the collection after I add packages) becomes very easy. Slackpkg has a powerful feature called templates, and with slackpkg+ added, it is possible to create a template containing multiple packages from one or more repositories.
For my DAW package set I created a template and host it here:  http://www.slackware.com/~alien/tools/templates/ with the name “daw.template”. Download this daw.template file and copy it into your local /etc/slackpkg/templates/ directory. Then, run:

# slackpkg install-template daw

…and slackpkg will prompt you with a list of all the packages from this template that you have not yet installed. For better readability in the example below I use the parameter “-dialog=off” so that the program outputs to the standard output instead of showing a ncurses dialog window:

# slackpkg -dialog=off install-template daw

NOTICE: pkglist is older than 24h; you are encouraged to re-run 'slackpkg update'
Looking for packages in "daw" template to install. Please wait...DONE
[ Repository ]              [ Package ]
  alienbob                    cecilia5-5.4.0-x86_64-1alien.tgz

Total package(s): 1
Do you wish to install-template selected packages (Y/n)?

In that sense, the “slackpkg install-template <templatename>” works similarly to the “slackpkg install <repositoryname>” command: it will install any package that is not already present on your computer.
After a “slackpkg install-template” action, you can fall back to your regular “slackpkg update && slackpkg install-new && slackpkg upgrade-all” routine of daily package management. You would have to run “slackpkg install-template daw” only after you read in my blog that I added a package, or if you had not yet installed the complete set and need (some of) the remaining packages.

Ideas? Enjoy! Eric

 

© 2024 Alien Pastures

Theme by Anders NorenUp ↑