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.
- 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.
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
Great article AlienBob! Thanks!
My oh my! I was observing these DAW moves and the itch to travel back in time to the mid 80’s was growing bigger. That was when I first setup an apple ][ with a MIDI interface (both cloned hardware because the closed marketing in my country on that time) for my dad’s studio. Maybe that moment has arrived…
Great article, Eric!
PS: Jen will love this.
Well you went all out with the configuration write up, much thanks for that! I have had that linuxaudio.org page bookmarked for the last couple year now but I have never been able to check all the boxes that their scanner mentions for improvement. Thanks for taking the guesswork out of that.
I think I’ll go with testing the DAW iso for now since the setup is all there and I can leave my regular slackware configuration for daily use. I used to run a setup where I would reboot with an initscript (PAM made this way easier!) and all the tweaks that I could manage but I think having a standardized environment from the USB iso is a nice feature. My laptop has 8GB of RAM so loading ‘toram’ should be good to reduce any io bottleneck with my USB audio interface, which is also a Focusrite Scarlett, but the 18i8 model (and I have a rode NT1 as well, great mic for its price range!).
I just have to remember to set up a save directory on my SSD for recording projects, otherwise space may fill up fast!
Thanks again Eric!
Nice! Got nothing to add…I don’t do much with MIDI, because I do a lot with just intonation, so MIDI-mapping (or remapping) doesn’t always make much sense, especially if you don’t assume the same number of pitches within an octave. Also, I synthesize audio, rather than record most times. I will say having PAM makes things a ton easier.
But having this written up in such a concise manner is a boon. I could’ve used it when I was first starting out, instead of learning the hard way.
I used to use pasuspender before starting whatever program I was using, but so long as jack is running, it’s overkill. I was pleasantly surprised to find out that pulse isn’t as big a pile of crap as it was. 🙂
Would be fun to have a Slackware music/art show ‘n tell sometime. Which would mean I’d have to get off my ass and actually finish something.
Thank you for writing this up!
I started using JACK as my main audio server 5-6 years ago on Slackware, before that having Pulseaudio and before that pure Alsa, and all I can say is that audio has gotten so much easier over the years.
When I started playing with JACK I used to have to do alsa loopback stuff that would crash regularly so that non-JACK aware programs could work, then Cadence came along and made managing the non-JACK aware connection much easier, with setting up pulseaudio, starting and stopping everything etc.
Then something clicked in my config or pulseaudio/jack and I have been able to simply start JACK, pulseaudio switches to JACK sink/source, run Non-Session-Manager to start session and make connections and audio is up and running.
And now with the PAMification of Slackware, RT access with JACK is so much easier!
It’s been awhile since I messed with Cadence (still use and love Catia!) but I highly recommend playing with it at least. (Anybody not just alienbob)
I have been testing out the Slackware Live DAW Edition iso on a USB stick to see how far I can push the performance in terms of latency when live recording. I’d like to share my results here so others can have an idea what the DAW setup is capable of.
First the performance will be heavily dependent on hardware. For reference, my current rig is a Dell XPS13 laptop with an Intel i5-6200U and 8GB RAM, and a Focusrite Scarlette 18i8 (2nd gen) USB3 audio interface. Also when recording with Ardour I save to a partition on my internal SSD (nvme), rather than using the USB storage.
For testing total roundtrip latency, I connected the monitor output to audio input 1 on the 18i8 using a patch cable (this loops the output back to the input). Start jack if it isn’t already (and make sure jack is set to the audio interface, not onboard sound!). Then open a terminal and run ‘jack_iodelay’, which is tool packaged with jack that is used for measuring total latency.
Once jack_iodelay is running, open the ‘connections graph’ in QjackCtl, you will find a jack_iodelay module with one input and one output port. Connect the input port of jack_iodelay to the audio input, and the output port of jack_iodelay to the monitor output. jack_iodelay will generate tones on its output, and then measure the delay taken to get back to its input (through the patch cable), reporting this value to you. Note: this number is always higher than the ‘calculated’ latency that is displayed in QjackCtl, since it includes additional latencies introduced by the hardware. From boot, Slackware Live DAW has jack configured at 256 frames/period, 2 periods/buffer, at 48kHz sample rate. This calculates to a 10.7msec latency, but measures out at 26.785msec round trip by jack_iodelay on my hardware.
You can push the frames/period lower and try combinations with 2 or 3 periods/buffer to reduce latency further. The downside is the hardware has to work harder to keep up. At some point it wont be able to and xruns will start to occur.
I experimented to find how low I can take the settings before xruns start and got my hardware down to 32 frames/period, 3 periods/buffer, synchronous mode, without xruns (and reasonable CPU load). This translates to a calculated latency of 2msec, and measured at 4.889msec round trip by jack_iodelay. Note that synchronous mode has slightly lower latency than asynchronous mode (you can toggle this in QjackCtl). Also note that adding more plugins or running other software will increase CPU load and increase the possibility of xruns. I like to keep plugins minimal, do my recording, then relax the settings when editing and latency isn’t as important.
I’d say these are pretty good results, considering that below 10msec latency is generally imperceptible to the ear when playing. I also didn’t notice much difference when running from the USB or from RAM when testing. For a comparison, when I used to run a realtime kernel and attempted to configure the system myself, I only ever got it down to 10msec roundtrip at best with the same hardware. To get anything lower than this current value I would probably need to switch to a rig with a PCI sound card.
If you bothered to read this far, I would like to also point out there is a further use to measuring your latency with jack_iodelay: It provides recommendations for input and output latency compensation settings. Once you find a setting that will work without xruns, run jack_iodelay again and note the recommended delay settings. Then go to the advanced settings in QjackCtl and enter the values in the ‘Latency I/O’ section. Jack has a latency API that clients like Ardour can use to compensate latency for you. This is useful in Ardour when recording a new track over another track that is played on the monitor. Ardour will adjust the playback delay and recording delay so that everything remains synchronized in the end.
Wrote out more than I expected to!
Hi Bob,
Thanks for this big write-up. I like to think that this place allows people to share ideas and knowledge and it’s not just a one-way communication from me to you all. Your comment falls straight into this category. There’s some stuff I need to digest, or rather: start playing with (re: jack_iodelay).
About the DAW Live ISO – if I understand correctly, the configuration I used is as good as any and relatively well-performing? Anything you came across that did not have correct defaults or was missing?
It is good to hear that a DAW Live when run from the USB stick gives you roughly the same user experience in terms of speed and responsiveness, compared to when the OS is completely residing in RAM.
In the meantime I have added Cadence to my repository for people who prefer it to QJackCtl. I plan on including it in the next update of the DAW Live ISO (liveslak scripts have already been updates and so is http://www.slackware.com/~alien/tools/templates/daw.template)
jack_iodelay used to be a separate program called jack_delay. It’s useful to measure your hardware latency for compensating so the jack team added it as jack_iodelay. ‘man jack_iodelay’ has decent information, and this latency compensation chapter of the Ardour manual is informative as well: https://manual.ardour.org/synchronization/latency-and-latency-compensation/
I haven’t found any problems with the config that you have set up so far. The default jack settings might be a little optimistic for an on-board sound card and would probably xrun. Not a problem with a dedicated interface though.
The only thing that I have used in the past that I don’t see here is ‘rtirq’, which is a script to set IRQ priority for audio hardware in conjunction with a kernel running with threadirqs (https://alsa.opensrc.org/Rtirq also on slackbuilds.org). Based on what I’ve read I think I am pushing the Scarlett to is maximum ability here so I don’t think that there’s much to improve on the DAW side (in my case).
I have used Cadence in the past with KXStudio. I’m not sure what it does differently than QJackCtl, now that it has ‘graph connections’. I guess if you’re adding it I can play around with it and find out. I haven’t used a Slackware Live USB for more than an install or repair tool until now, but that should install on a persistent USB made with iso2usb.sh just fine, correct?
Also a side note: I have been checking out musescore lately and it looks like the ‘palettes’ are missing, at least on my install. There are a couple very recent bug reports from arch and opensuse with the same symptoms that I’m keeping my eye on but it seems like an issue caused from qt5 5.15.0. Bug reports here for ref: https://musescore.org/en/node/307238 https://musescore.org/en/node/307236 https://musescore.org/en/node/306817
Cheers,
Bob
Previously I’d used a little-known distribution called io GNU/Linux, but I’m glad to see this, especially as Slackware 15.0 is now (?) approaching.
I have a few comments. First, I haven’t composed anything recently, but when I was composing I tended to use LMMS or Sonic Pi. I wasn’t surprised not to see Sonic Pi among the included packages, but I thought LMMS was pretty standard. Could at least one of them be included? Secondly, and more importantly, when I try to download from martin.alienbase.nl, I get an error saying that the SSL certificate is not trusted.
Hi Matthew. The SSL certificate for martin is a CACert certificate, these are not supported by default by the big browser makers since they cannot control the CACert grass-roots community. However it is trustworthy and here is the instruction to incorporate their CA root cert into your computer: https://alien.slackbook.org/blog/adding-cacert-root-certificates-to-your-slackware/
Instead of LMMS I chose Ardour, matter of taste.
I looked at Sonic Pi but it requires a lot of Ruby stuff which I would also have to add, and it uses SuperCollider as its engine. I have SC in my package set already, It’s kind of a ‘vi versus emacs’ discussion on which is preferred for actual live coding.
Hi Eric, thanks for the information. I did add the SSL certificate, but before I did so I also discovered that I could view the non-SSL version of the site, and also that several Slackware Live mirrors have the DAW software available as addons in SXZ format.
I tried both Ardour and SuperCollider. I still prefer LMMS and Sonic Pi, but LMMS is available on SlackBuilds.org. I’ll see what’s required to build Sonic Pi. I usually have Ruby and Erlang installed anyway. By the way, there’s now a Python music programming environment called Python-Sonic. It currently depends on Sonic Pi, but it looks like there are plans to use SuperCollider alone as the back end. Site here: https://github.com/gkvoelkl/python-sonic
I’ve had a little time to play around with Slackware Live DAW. My favorite program so far is MuseScore 3. Thanks for putting this together!
Hi Matthew. I have built an erlang-otp package in the meantime and will have a look at sonic-pi during my holiday. From what I saw in its sources, it will build all the required ruby gems from its own source tarball, so that would limit the amount of extra SlackBuild scripts I would have to write.
As for LMMS, I checked the SBo script and it does not list too many dependencies, and most of those are already part of my own DAW package set anyway. So, perhaps another project for my upcoming holiday. The idea behind Slackware DAW Live is to try and offer everything a musician or sound artist could ever need on a Linux OS. While I am trying to limit the duplication of functionality, I can understand that for a complex program with similar functionality – like Ardour of LMMS – you would want to use the one you mastered.
Hi Eric,
I was very excited to read your post, and I followed it and set up my Slackware with all the required software. All I needed is to get the necessary hardware.
I have an old Kurzweil PC2x keyboard that has a midi interface built in, however, I was unable to make it work. Slackware and Ardour did recognize it, but no signal came across. I tried to look information about it on the web, but I found very little, indicating that this keyboard might be just too old. It was made when Windows XP was the current OS. So I shopped for a MIDI keyboard. I tried to find information about Linux compatibility, but again I found almost nothing. I asked the clerk at the store, and he said that all these MIDI keyboards should work, since they are all class-compliant. WRONG! I ended up buying a Arturia Keylab Essential 61, and it did not work with Slackware. Again it was recognized, but no signal came across. Then I tried it under Windows, and to my dismay I learned that this keyboard will only work if it is registered with a particular PC, and it can be registered to a maximum of 5 PC’s. The software that maintains this registration is only available on Windows and Mac, so again, I am out of luck. The keyboard cannot be returned to the store 🙁
All this leads to my question. Do you have information about MIDI keyboard compatibility with Linux? I don’t want to be stuck with Windows, and I will buy another keyboard, but first I need to make sure it’ll work with Linux.
Karl
Hi Karl,
Actually I had a similar discussion via email with Bob Funk, who regularly comments to my audio-related articles here on the blog. I will paraphrase what he replied when I told him I was unable to make my USB MIDI keyboard work in zyn-fusion:
It can be a little tricky to use a MIDI keyboard which is connected via USB.
If you use a proper MIDI cable from the keyboard to your audio card’s MIDI port then you shouldn’t have a problem since JACK will simply see it as one of the audio interface’s input streams. However, a MIDI keyboard plugged into another USB interface will be handled by ALSA instead of JACK. In this case the output of your ALSA MIDI keyboard will not be able to be connected directly to any JACK MIDI input (for instance to feed into Ardour, or into Zyn-fusion).
To fix this, you have to have a2jmidid installed. You run ‘aj2midi_bridge’ in a terminal, which then exposes its interface in jack’s connection graph. Then you can route the ALSA MIDI output into a2j_bridge and use the JACK MIDI output of a2j_bridge to connect into e.g. an Ardour track with the zynaddsubfx plugin.
I’ll consider running a background instance of ‘a2j_bridge’ on startup of my DAW so that it is always available.
Thanks, Eric.
Did you mean a2jmidi_bridge rather than a2j_bridge? Anyway. I am getting hopelessly confused about what is connected to what, and in what order. I found a decent guide that gave me a partial understanding at Ted’s Linux MIDI Guide, http://www.tedfelix.com/linux/linux-midi.html , but I still don’t see the big picture. Any guide, or documentation you can recommend? I looked at SudioWare, and found practically no information about how to use the slew of audio applications it contains together.
Karl
Karl
Indeed I meant a2jmidi_bridge. But it may be even better to start a2jmidid, the daemon program which will create bridges on demand. In my QJackCTL setup I have “/usr/bin/a2jmidid -e &” as the script to start after QJackCtl has started JACK, and a “killall a2jmidid &” command to run after the shutdown of JACK.
As for using applications and attached hardware under the control of JACK, you just need to experience and experiment. Conceptually it works a bit differerently from ALSA powered system, but using the Graph window of QJackCtl you will easily be able to connect the output of any program or hardware component to the input of the next program or hardware component.
Great stuff!
I have just got my first Slack-live usb going, and was surprised while
reading to install it that Slackware has – for many years – offered some sort of audio production resources. I will certainly try your DAW as soon as I can.
I understand it is to be found in the Bonus folder at the repository, is that right?
I am not a professional musician, just an amateur student of music. I have been reading about doing audio on linux for a couple years – used first Tango, then Av Linux, then tried KXStudio and then Gentoo which was too tough for me. I am using UbuntuStudio at the moment. I am shocked I had not heard of Slackware audio production capabilty. Certainly my own fault although I believe to be quite good at googling.
But my point in writing here is to thank for excelent information, but above all for the friendly and clear way it is presented.
Unprecedented in my long history of reading about both Linux and audio production.
I am looking forwards to become a full time Slackware user.
Actually, STUDIOWARE is the project which offers a rich multimedia experience on top of Slackware and has been doing so for years. Not just the tools to create and produce music but also several video editing tools.
The conceptual start of a DAW variant of Slackware Live is little more than a year old now. It began as a research into the availability and viability of Open Source tools for music making on Slackware, this evolved to a deep-dive on how to configure Slackware optimally as a low-latency workstation; and all of that knowledge went into Slackware Live DAW.
And I must say, with the invaluable help of several frequent visitors of my blog with lots of experience and quite knowledgeable about the subject.
So, Slackware Live DAW is a full ISO by itself, hosted at https://martin.alienbase.nl/mirrors/slackware-live/pilot/ . The collection of music production related packages it contains is separately available as an add-on squashfs module for the other Slackware Live variants, and that file is hosted at https://slackware.nl/slackware-live/bonus/ .
I must warn that the daw module is somewhat out of date – 6 weeks old means that on a Slackware-current installation, some packages could be broken by now.
I have ow managed to install from Slackware Live to two old laptops, one of which is my daily laptop and I am in the process of getting acquainted with Slackware, and I am already tempted to attempt installing Studioware in my 2010 macbook. it would be my first attempt to install Linux on a mac book.
I have had Debian, Ubuntu and Lubuntu in my iMac G3, and i have run Fedora and Mint in the ibook, from usb sticks. I have already shrinked the partition on the imac, and I am reaaly intent to try Studioware, but i wonder whether there might be specific issues – as opposed to ther Linux distros – I should be wary of.
Always thankful for you fantastic work !
Could you give an opinion on this ambition? Any suggestion from your side will be appreciated.
Studioware is not my distro, so I have no opinion about it.
Great work!!! a wonderful thing to learn how to run this programs on slackware. I’ve been doing music on ubuntu studio because I didn’t know how to configure slackware for those tasks. I’ve learn a lot using slackware and I’m glad I can now use it for making music. Thank you for all the packages you made available for slackware.
Glad to hear you found this useful 🙂
I was considering creating a package which basically applies all the above settings from the article to your computer when you install it. Would that be adding value?
If you have such a package I would gladly install it and see how that goes on in my computer, maybe I could give some feedback.
What I did was to follow the instructions in this article and the other one “Explorations into the world of electronic music production” and so far this DAW environment is going great. Both articles are straight forward. Personally, I had been struggling to configure slackware 14.2 for music production for sometime now and had a lot of issues running the jack server (lots of xruns and troubles recognizing my audio interface (Zoom H6 recorder USB). That’s why I was so happy to find this article. After I read it I upgraded to slackware current which I guess I should have done long ago anyway.
Now, I’m not sure if creating a package specifically for this configuration is necessary, as I said the article is very clear and leaves some options for things like the absence of PAM or for different Desktop Environments, but hey! I’m no expert, In my case I didn’t even know if I had PAM installed, I didn’t even know what PAM was 🙂 so I guess these kind of things are better left open for different cases. Following the article let me learn new things which is why I like using slackware. The liveslack daw image is another good option for some people.
Also, I find very useful the pulseaudio-jack package. Before this I was always struggling with pulseaudio and jack, to the point which I had to do without pulseaudio for a while. This package solves this conflict smoothly.
I still had some minor trouble when launching jackctl and sometimes the jack server wouldn’t start because it couldn’t get hold of my usb audio card. Sometimes this problem arises depending if the usb audio card was already plugged and running before launching qjackctlI or vice-versa. I solved this by doing “pactl set-default-sink jack_out” and by running the scripts from within the qjackctl setup options; Execute script on startup ‘pulseaudio –kill’ and Execute script after startup ‘pulseaudio –start’ and now qjackctl gets my audio interface every time.
As for the DAW packages I recommend adding qmidiarp (http://qmidiarp.sourceforge.net) and qtractor (https://qtractor.sourceforge.io). qmidiarp has a nice arpeggiator plus a good old school step sequencer with LFOs. I use qtractor to record and edit midi files mostly as in Ardour I find it hard to do this.
Right now I’m trying to reduce the overall latency and your article in the slackware wiki (https://docs.slackware.com/howtos:multimedia:digital_audio_workstation:minimizing_latency) has been of great help. Thanks again!
Thanks Federico for this extensive response.
If I would create such a “daw-setup” package I will have to take care not to mess up any existing user configuration, so the script will have to do a lot of checking for configuration files and their content.
I do think that for some users a ready-made package may be easier than reading the above article and its relatives. But as you say, reading these articles actually increases your level of knowledge about how a workstation is setup for real-time audio, and if it is all together in one place to read, it is probably of more value than installing a package (which will not increase your understanding of what is being changed).
I will look into qmidiarp and I remember looking at qtractor in the past. Don’t know why it did not make the cut back then, probably lack of time.
The Wiki articles were actually written by Bob Funk, he also left quite a lot of useful comments here on the blog. I merely translated his TeX sources into Wiki syntax and posted them.
So I went ahead and added qmidiarp as well as qtractor to my repository.
They will also be included in the upcoming DAW Live ISO you can download from https://martin.alienbase.nl/mirrors/slackware-live/pilot/ . I am currently generating it (timestamp on the server should be 20 September or newer).
Nice additions! Thank you and Bob Funk if he gets to see this.
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.
DSP is done on the CPU(all the software), not to be confused with a DSP-processor . That was a bit confusing 😀
I agree this is is a confusing statement, partly due to my own ignorance.
As I understand it, the “”DSP load” is the percentage of time which the CPU needs to spend on processing the audio buffer, in relation to the total latency in the sound handling as defined by the product of samplerate and buffer size. The higher that percentage, the higher the chance that the CPU can’t keep up its digital signal processing from time to time, which then results in an xrun.
It doesn’t help that the DSP term is thrown around for multiple things. It could be referring to a DSP chip, a DSP “accelerator” like Universal Audio’s UAD line (dedicated external DSP), or “DSP load” in jack audio.
DSP load in jack audio is as Eric states. Essentially its a percentage of the amount of actual time the CPU takes to process audio, versus the time of a single buffer period. Hitting 100% DSP load means that the CPU can’t keep up to the rate that audio is buffered, and xruns will occur.
However, xruns can also occur at lower %DSP loads for other reasons like the CPU switching frequencies for the various power saving modes in modern CPUs. Running the CPU at a fixed stable frequency helps, hence running in performance mode (and limiting CPU freq and c-states if necessary).
Hi!
I have been using Slackware Live Mate on my macbook 7.1 -2010 (16GB) for almost a year and I want to install Slackware on a ssd external disk to be used with this macbook.
I have read much about the problem some distros have with full install to external disks and have found not as much on how to deal with this questions, although there quite a few articles on that. Unfortunately I haven’t found anything to assure me of how to proceed with installing present Slackware on the model I have.
I think I once read something you wrote about running Slackware on makbook, but I can’t find it, forgive me if I am wrong.
Could you offer any advice ?
Next time, you should use the appropriate blog post for your comments. Your question has nothing to with Digital Audio Workstation setup.
I did not write about Macbooks, I am not a fan of Apple and its hardware/software products.
If you want to install Slackware onto an external hard drive, that is entirely possible if you take care of some additional configuration during the setup and before you reboot.
It’s similar to what liveslak also needs to do:
1) ensure that the USB subsystem has been initialized before the init script inside the initrd image tries to access the computer’s block devices. Slackware’s mkinitrd command has a “-w” switch where you can set the number of seconds to wait during boot. Usually, 5 to 10 seconds should be sufficient. You can update your initrd (in the already installed new Slackware system but before rebooting) by chroot-ing into your fresh installation, editing /boot/initrd-tree/wait-for-root and changing the value there, followed by the command “mkinitrd” to re-generate the initrd and then “lilo” again if you installed and configured lilo.
2) In your /etc/fstab file, do not reference disk partitions by their device name, because those can change if you dynamically add and remove external storage devices. It’s better to give your disk partitions a label or else lookup their UUID. The “blkid” command will show both the labels and the UUIDs. For instance:
/dev/sdc1 / ext4 defaults 1 1
could become:
LABEL=MYSLACKROOT / ext4 defaults 1 1
Many thanks!
Excuse me for wrong ssumption and wrong blog – I forgot to mention thar my objective is to have DAW on my machine, in order to produce music at home studio level.
I am amazed at how supporive you and the Slackwre community are!
Hi! First of all thank you for maintaining this! Slackware was my first distro some 20 years ago and by the hand of Bob i’ve decided to move back to it! I already had quite a successful venture into pro audio linux setups several years ago using manjaro and endeavourOS, but bleeding edge distros are no good for serious production work, so i had to split. As of now due to my unfortunate location there’s not much going on in terms of production but there’s literally too much time, which led me back to find that beautiful work of yours free of the pipewire horrors. I bought a Lenovo 495 specifically for using with Slack, and your DAW edition works out of the box from the flash drive, however i have a specific question before i make the move: Mostly, i work in Harrison Mixbus, which is built around Ardour, so they provide linux versions, but to run some of the windows VST’s i still require in my workflow i’ve preivously used “Yabridge” wrapper, which allows to run Win VSTs via Wine. There was a specific Wine build with various patches for realtime audio, called Wine-NSPA, which, i believe has 32-bit dependencies and is built specifically for Arch distros by its author. Can you tell if that is possible to compile it on Slackware if i’ll add multilib support? This will be much appreciated! Once again thank you for your work and cheers from Mordor.
Hi Nem Pad. Welcome back to Slackware and I hope you will make good use of my DAW package set. Keep me informed of your adventures.
Yabridge can be built using the SlackBuild script at https://slackbuilds.org/repository/15.0/audio/yabridge/?search=yabridge but I do not think you should attempt to use it with Wine-NSPA. Yabridge actually requires a recent version of Wine-staging (8.x). And wine (-staging) version 8.5 is precisely what I already offer as a package: https://slackware.nl/people/alien/slackbuilds/wine/ . This does require multilib but adding that to your computer is trivial.
If you decide to look into Wine-NSPA, realize that the developer strongly advises to only use it in conjunction with a particular kernel build ‘linux-NSPA’. Both of these are Arch specific and I do not know how successful you would be using this on Slackware.
Thanks, Eric! I’m certainly in for a ride with the Slackware for old times’ sake and also because the word slack has significant value in my book. I guess I’ll finish a grind core mix i own to some of my fellow Mordor people and will move right in to check if the wine staging will satisfy my needs. My main goal is to run “Jamstix” AI drummer, (which is the most exciting VSTi of recent years creation for me) in Linux, which as I’ve read was done already, plus some of the Empirical Lab’s compressors. I’ll be sure to report back to you re current wine-staging being enough for this. As for the wine-NSPA, as far as i can remember, I’ve ran it on Manjaro without the mentioned kernel with good results, i can’t actually remember which kernel i used, but it definitely wasn’t the NSPA one. Thanks for your quick answer!
Hey Eric,
Have you tried compiling MuseScore 4.1.1 yet?
From what I understand they’ve done a huge code overhaul which should fix some of the problems I’m running into with 3.x.
Also: What instrument(s) do you play (why else would you need a DAW)?
I’m a vocalist, guitarist and I’m learning to play the piano. If you ever wanna jam, I live in the countryside next to Veldhoven.
Cheers,
NoKey.
I’m certain that Eric will offer an upgrade when he can find the time.
Even if there were a lot of changes introduced in MScore-4, it builds OK if you just bump the version number in the buildscript.
Only snag is that although I build it using the official stable source file marked as stable, it identifies itself as a development version suggesting I should upgrade.
There’s also an AppImage version that runs fine on Slackware.
And there’s a 4.2-beta version in the pipeline.
FIxed the faulty dev version stamp by editing line 49 in the CMakeLists.txt file in the source package
from
set(MUSESCORE_BUILD_MODE “dev” CACHE STRING “Build mode”)
to
set(MUSESCORE_BUILD_MODE “release” CACHE STRING “Build mode”)
Those rascals!
Apparently they changed the parameter “MUSESCORE_BUILD_CONFIG” of MuseScore3 to “MUSESCORE_BUILD_MODE” in version 4. Look for the former in musescore.SlackBuild and change it into the latter. No patch needed.
Hi NoKey.
On “why else would you need a DAW”… I hate to break the news but I am not a musician.
I do own some musical instruments but “play them” may be far-fetched. I play an inherited electrical bass guitar at beginner level, I can play simple tunes on my keyboard and I have some groove boxes that I like to mess with (Teenage Engineering stuff mostly, also an Electron Model:Cycles).
Mostly I created Slackware DAW Live because I am worth more as an enabler for actual musicians. I have friends who play music or DJ and it was my desire to show that you can use Slackware as the base for your studio. I needed instruments to test my produce, but know that the sounds I make are that: sounds, not music 😉
Well in that case I am extremely thankful to you that you did create Slackware DAW Live. Even though I only really use the slackbuilds scripts for all the music software.
I sing* and play guitar at a pretty advanced level. Next to that I’m learning to play the piano and it seems I also have a talent for making vocal arrangements.
My piano teacher was very impressed at my first attempt at a vocal arrangement. So now she decided t also teach me harmony (harmonieleer).
I have played in rock bands and progressive metal bands but quit playing bands about 20 years ago.
I’ve done an interactive live music show for an internet radio station from my living room with this setup:
http://slabexchange.org/various/LITLR-studio-setup.jpg
But I’m still just an embedded software designer for one of the many electronics design companies in Eindhoven. But my degree is in electronics.
*Michael McGlynn, a very well known choral music composer and arranger once said to me after a performance when I apologized about making a mistake in a song somewhere: “Oh no, you were brilliant” (I was kinda flabbergasted there though).