Alien Pastures

My thoughts on Slackware, life and everything

Tag: jack

Some recent package updates: chromium (-ungoogled), ffmpeg, handbrake, pipewire-jack

September 1, 2023 / / 23 Comments

Chromium, regular and un-googled.

Google is speeding up its Chromium release cycle. Let’s see if I can keep up since I also build the -ungoogled variant. The latest update is 116.0.5845.140 and addresses a vulnerability.
You can now upgrade to my latest chromium and chromium-ungoogled packages. The updated Slackware 15.0 and -current packages both for chromium and chromium-ungoogled are available in my repository and its mirrors (like my own US server and the UK mirror).

FFmpeg.

A recent upgrade of Vulkan in slackware-current prompted a rebuild of the ffmpeg 5.1.3 distro package, and for the same reason I had to recompile my enhanced ffmpeg package for -current. I used the opportunity to add an embedded version of SVT-AV1, an open source AV1 video encoder originally developed by Intel in collaboration with Netflix and later adopted by the Alliance for Open Media. My ffmpeg package already contains an AV1 decoder: the dav1d library, but now you can have a go at creating your own video in AV1 format.
Get ffmpeg-5.1.3 for -current here (unrestricted distribution) or here (this version can encode AAC audio and hence restricted to distribution outside the US).

Handbrake.

The version of this package targeting slackware-current also needed a recompile due to the Vulkan update in -current and here I used the opportunity to apply a minor version upgrade.
Get handbrake-1.6.1 here (unrestricted distribution) or here (this version can encode AAC audio and hence restricted to distribution outside the US).

Pipewire-jack.

In slackware-current, pipewire is a moving target. I know that a lot of people have switched from using pulseaudio and jack to just pipewire with varying levels of success. I keep offering the Jack Audio Connection Kit support libraries for pipewire which are not present in the Slackware pipewire package, simply because Pat compiles pipewire without jack installed.
Note: my pipewire-jack package is not replacing Slackware’s pipewire! It’s an add-on which depends on my jack2 package being installed as well. It’s quite similar in purpose to my pulseaudio-jack package which aims to add support for Jack in pulseaudio.
Get pipewire-jack-0.3.79 here.

Enjoy the weekend! Eric

Configuring Slackware for use as a DAW

June 24, 2020 / / 42 Comments

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

Setting up Jack Audio in Slackware

January 2, 2014 / / 42 Comments

Note: this article has been superseded by the (much less complex) instructions in a newer article “Configuring Slackware for use as a DAW“.

If you are using your computer as a Digital Audio Workstation (DAW) then the ALSA sound subsystem is just not up for the task. Musicians and audio professionals prefer to use Jack Audio on Linux. Let me quote from the Jack Audio web site:

What is JACK?

Have you ever wanted to take the audio output of one piece of software and send it to another? How about taking the output of that same program and send it to two others, then record the result in the first program? Or maybe you’re a programmer who writes real-time audio and music applications and who is looking for a cross-platform API that enables not only device sharing but also inter-application audio routing, and is incredibly easy to learn and use? If so, JACK may be what you’ve been looking for.

JACK is system for handling real-time, low latency audio and MIDI.

We “ordinary” users of Slackware don’t usually have a need for Jack. It makes your computer’s sound subsystem more complex, meaning that more things can go wrong (where you end up with distorted or even no sound) and that fixing things requires more knowledge.

However there are cases even for non-musicians to want to install Jack Audio. I am one of them. As I explained in my previous post, I want to record videos of programs running on my desktop, along with the comments I may record through a microphone. When I selected SimpleScreenRecorder as my tool for doing this, I found out that it needs Jack in order to record the audio (but come to think of it… after reading bradpit’s comment in the previous post I realize that there may be a way around Jack – something I will check out soon and report if I find anything worth mentioning).

This article is meant to show you how to install and configure Jack Audio, and how to configure ALSA so that applications will still have sound even if they are unaware of Jack (Jack grabs the computer’s sound hardware and won’t allow ALSA applications to use it).

The article will center around you, being the one behind the physical computer. No system file needs to be changed, all configuration is done in your own home directory, for your use only. If someone else logs in, he or she will not be bothered by Jack and everything will work as before.

 

Installing Jack Audio

In order to install Jack Audio, you need the following packages: jack and qjackctl.

The qjackctl package contains the “de facto” configuration utility for Jack Audio, also called qjackctl. It is a Qt-based graphical program which allows you to configure “several JACK daemon parameters, which are properly saved between sessions, and a way control of the status of the audio server daemon” according to the program description. It also allows you to configure and autoload the patchbay and offers full connection control.

qjackctl_main

Configuring ALSA

The goal is to have a configuration where ALSA applications can access a “audio hardware” device even when the real device is locked by Jack Audio. That way, ALSA applications will not complain about unavailable audio hardware. I will show you how to provide ALSA with such a virtual hardware, and ensure that all sound which goes into that virtual hardware will be picked up by Jack and played through your speakers (hence the phrase “bridged”).

This “virtual hardware” is provided by the ALSA loop driver. When loaded into the kernel, this driver provides a pair of cross-connected devices, forming a full-duplex loopback soundcard.

First: load the kernel module (as root)

# /sbin/modprobe snd-aloop

You should add the above command-line to the file “/etc/rc.d/rc.modules” or to “/etc/rc.d/rc.local” so that the module will be loaded automatically on every boot.

The driver creates 8 independent substreams by default, but we need only two. Therefore you can add the following line to a (new) file called “/etc/modprobe.d/alsaloop.conf”:

options snd-aloop pcm_substreams=2

Next: write an ALSA configuration file which uses the new loopback devices

Create your ~/.asoundrc file as follows – if this file exists in your home directory, please back it up first!

# ------------------------------------------------------
# hardware 0,0 : used for ALSA playback
pcm.loophw00 {
  type hw
  card Loopback
  device 0
  subdevice 0
  format S32_LE
  rate 44100
}

# ------------------------------------------------------
# hardware 0,1 : used for ALSA capture
pcm.loophw01 {
  type hw
  card Loopback
  device 0
  subdevice 1
  format S32_LE
  rate 44100
}

# ------------------------------------------------------
# playback PCM device: using loopback subdevice 0,0
pcm.amix {
  type dmix
  ipc_key 196101
  slave {
    pcm "loophw00"
    buffer_size 8192
    period_size 4096
    periods 2
  }
}

# capture PCM device: using loopback subdevice 0,1
pcm.asnoop {
  type dsnoop
  ipc_key 196102
  slave {
   pcm loophw01
   period_size 4096
   periods 2
  }
}

# ------------------------------------------------------
# software volume
pcm.asoftvol {
  type softvol
  slave.pcm "amix"
  control { name PCM }
  min_dB -51.0
  max_dB   0.0
}

# ======================================================

# ------------------------------------------------------
# duplex device combining our PCM devices defined above
pcm.aduplex {
  type asym
  playback.pcm "asoftvol"
  capture.pcm "loophw01"
  hint {
    description "ALSA->JACK Loop Bridge"
  }
}

# ======================================================

# ------------------------------------------------------
# Mixer control definitions to keep JACK and some other apps happy
ctl.amix {
    type hw
    card Loopback
}

ctl.asnoop {
    type hw
    card Loopback
}

ctl.aduplex {
    type hw
    card Loopback
}

# ======================================================

# ------------------------------------------------------
# for jack alsa_out: looped-back signal at other end
pcm.ploop {
  type hw
  card Loopback
  device 1
  subdevice 1
  format S32_LE
  rate 44100
}

# ------------------------------------------------------
# for jack alsa_in: looped-back signal at other end
pcm.cloop {
  type hw
  card Loopback
  device 1
  subdevice 0
  format S32_LE
  rate 44100
}

# ======================================================

# ------------------------------------------------------
# default device

pcm.!default {
  type plug
  slave.pcm "aduplex"
}

When you save that file, its content will re-define your ALSA configuration with immediate effect. KDE may complain about hardware that was added or went missing, you can ignore that for now.

What these definitions do for ALSA, is to create a new full-duplex PCM device called “pcm.aduplex” with a description (which you will see mentioned in your programs’ ALSA device selectors) of “ALSA->JACK Loop Bridge”. What these definitions also do, is to create additional PCM devices for capture (pcm.cloop) and playback (pcm.ploop) which we will connect Jack to. That way, your ALSA applications are going to pipe their audio into one end of the loopback device and Jack will see this as incoming audio and play it on your speakers.

 You can test your new ~/.asoundrc file even though you will not hear a thing because the new virtual device is not yet connected to a real audio device (we will come to that in the next section). If you run the following command (under your own account – not as root) you should not see any error message:

$ aplay /usr/share/sounds/alsa/Front_Center.wav

Playing WAVE ‘/usr/share/sounds/alsa/Front_Center.wav’ : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

If you see errors instead of the above text, then there is something wrong with the ~/.asoundrc file you just created.

Configuring Jack Audio

You should use qjackctl to configure the jack daemon. Jack installs a D-Bus service which qjackctl will connect to. Qjackctl can launch the daemon by itself or attach to an already running jack daemon (the qjackctl tray icon will be green if it had to start jackd and orange if it connected to an already running jackd).

qjackctl_setup_misc

Qjackctl will write the jack daemon configuration to a file in your homedirectory: ~/.jackdrc .It will write its own configuration to a different file: ~/.config/rncbc.org/QjackCtl.conf

I found out that I needed to have a sampling frequency of 44100 (the Jack default) instead of what musicians usually use (48000) in order to prevent distorted sounds coming from ALSA applications (youtube flash videos!). Whatever frequency you choose, you will need to use the same sampling frequency in ~/.asoundrc (see above) and for jackd.

qjackctl_setup

Using qjackctl, you can easily configure jack to use the soundcard hardware to which your speakers are connected: it shows a list of available devices in a dropdown menu. If you want to construct the jackd command-line manually, the names of all hardware devices can be obtained by running the following command:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: VT1708S Analog [VT1708S Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
card 0: NVidia [HDA NVidia], device 1: VT1708S Digital [VT1708S Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

The content of my ~/.jackdrc file looks like this:

/usr/bin/jackd -r -m -dalsa -r44100 -p1024 -n2 -m -H -D -Chw:NVidia -Phw:NVidia

The various jackd parameters all correspond to selections in the qjackctl dialog window.

Now when jack starts, it will still not know what to do with our modified ALSA configuration. A few commands need to be executed to form a bridge between ALSA and Jack using  the loopback driver. This is done most easily by creating a script file (for instance as user root create the file “/usr/local/bin/loop2jack” so that other users of your PC can use it as well) and in that file, add the following:

#!/bin/sh
#
# script loop2jack, located in /usr/local/bin
#
# Start jack if it is not already running:
/usr/bin/jack_control start
# loop client creation
/usr/bin/alsa_out -j ploop -dploop -q 1 2>&1 1> /dev/null &
/usr/bin/alsa_in -j  cloop -dcloop -q 1 2>&1 1> /dev/null &
# give it some time before connecting to system ports
sleep 1
# cloop ports -> jack output ports
/usr/bin/jack_connect cloop:capture_1 system:playback_1
/usr/bin/jack_connect cloop:capture_2 system:playback_2
# system microphone to "ploop" ports
/usr/bin/jack_connect system:capture_1 ploop:playback_1
/usr/bin/jack_connect system:capture_2 ploop:playback_2
# done
exit 0

Don’t forget to make the script executable:

chmod +x /usr/local/bin/loop2jack

This script should to be started after jackd has been started, but if jackd is not yet running, the script will start it for you. You can run it manually to see if there are any errors in your ~/.asoundrc file that you have to fix first. You can use qjackctl to run this script automatically when it starts:

qjackctl_setup_options

In the above screenshot you will also notice how the patchbay definitions are made persistent – I will show why this is important when I get to the section on SimpleScreenRecorder.

 

Starting Jack Audio

You will want to start the  jack daemon before any of your ALSA applications start! The ALSA driver grabs the audio hardware as soon as an application tries to make a sound using ALSA. Desktop Environments like KDE and XFCE have a feature called “session restore” which means that programs which were running when you logged out, will be started again – automatically – when you login again. A program like Skype, or even the startup sounds of your KDE desktop, will prevent Jack from launching properly.

If you are in runlevel 4 (graphical login) then you can start jackd by adding an appropriate command line in the following file: ~/.xprofile

If you are in runlevel 3 then you can start jackd from your normal login, using the file: ~/.profile

For instance, I have added this text to my ~/.xprofile :

# Create the bridge between ALSA applications and JACK output:
/usr/local/bin/loop2jack

… which will solve all timing issues: the loop2jack script will start the Jack daemon if it was not yet running, and it will bridge the ALSA and Jack in- and output channels using our virtual loopback device. This way, qjackctl does not even have to start anything (but we will not change the qjackctl configuration, in case you need to stop and restart Jack during a desktop login session).

 

Caveats

You have to keep in mind that running Jack is now required after making these modifications to your ALSA setup! When Jack is stopped (or not started) your ALSA sound system is no longer bridged to the physical sound card and you’ll hear nothing.

Also note that you may have a system-wide ALSA configuration file “/etc/asound.conf” which may interfere with your setup. Your own ~/.asoundrc definitions are added on top of the definitions in /etc/asound.conf and do not replace them.

 

Reverting this bridged ALSA-Jack setup

Reverting to the original Jack-less configuration is easy.

  1. Stop the Jack daemon using the qjackctl menu, and then stop qjackctl

  2. Remove or rename the file ~/.asoundrc (and restore your backup if you had an earlier version of this file)

  3. Remove or rename the file ~/.jackdrc

  4. Remove the invocation of “/usr/local/bin/loop2jack” from your ~/.xprofile and/or ~/.profile scripts.

The steps (1) and (2) are sufficient to restore the default ALSA behaviour and steps (3) and (4) ensure that Jack will not interfere at next login.

Getting audio into SimpleScreenRecorder (SSR)

In the “connections” window of qjackctl, my computer’s audio layout looks like this when I have started SimpleScreenRecorder (read my earlier post about this video recording tool):

qjackctl_connections_ssr

It’s a fairly simple layout with just a single Jack input client (being SSR) and a single output client (the entry “alsa-jack.jackP5161.0” which is the VLC program playing music).

The connections you see here between Jack’s “monitor” outputs (which were activated by checking the “Monitor” box in qjackctl’s setup dialog) and SSR’s inputs are automatically created when SSR connects to the Jack server. This happens because I defined these connections in qjackctl’s “patchbay” and let them be automatically activated. It seemed to be necessary this way because I could not get the monitor’s output to start inputting into SSR except by creating manual connections everytime.

qjackctl_patchbay_ssr

This is how I was finally able to record videos of (programs running on) my Slackware Linux desktop. Feedback highly appreciated!

Eric

 

A simpler solution (but not as robust)

There is another way to route the audio to and from ALSA-using applications when Jack is the sound server. In http://jackaudio.org/routing_alsa you can see how to use the “ALSA Jack PCM plugin” which creates a new PCM type called “jack”. This is a lot simpler to setup than the above article but it is not as robust and flexible. I used this solution for a little while and was happy with it – until I found out that it will not enable me to record audio with the SimpleScreenRecorder. So I had to abandon it.

You will need my alsa-plugins package for this. This package has two dependencies: jack (naturally) and ffmpeg. Note that if you want to use alsa-plugins and you are running 32-bit software which plays or records audio (think of Skype, Steam games) and you are on a 64-bit Slackware system, then you will additionally need multilib (of course) as well as “compat32” versions of the 32-bit ffmpeg and jack packages.

 

References

These pages have been helpful (most important info in the first link):

A journey into recording sound & video in Slackware

December 30, 2013 / / 23 Comments

ssr When it comes to audio and sounds in Slackware, we’re happy to have ALSA as the sound subsystem. It works reliably, and has done so ever since it replaced OSS in Slackware all those years ago. In due course ALSA got capable of dynamically mixing multiple sound sources – which is basically what a sound server does, too. We were never plagued with the issues of other distros when they abandoned ALSA for PulseAudio.
When the Arts sound daemon of KDE was deprecated and finally removed with the release of KDE4, Slackware was left without a sound “server” that ran out of the box. We still have ESD, the Enlightened Sound Daemon but that one has limited use because of the wrapper programs it needs.
There are however scenarios where you wish Slackware had some sort of audio server. Until now, the only times when that thought crossed my mind it was related to streaming audio over a network – think of remote desktop sessions and virtual machines. I may write some more about that topic in a future post because I think I have the solution now – read on.

A more immediate need arose when I went looking for software that can record videos of my Slackware desktop – individual program windows and gameplay footage. My son is a huge Minecraft fan and wants to be able to do in Slackware what he already does with Fraps in Windows. My intention is to task him with creating some Slackware “end-user” videos to attract newcomers to the distro 🙂

It turns out that there really is not all that many good desktop video recording software in Linux land. I have tried recordmydesktop and like it well enough (that is how it ended up in Slackware’s “/extra” section) but it does not deliver stellar videos, in particular I don’t think it is suited for recording gameplay. It also produces OGG video only, which is OK since that gives you the only free and open video format and codecs… but I believe this design decision limits my options too much.

I read up on ArsTechnica’s attempts to record gameplay footage on SteamOS. To this day, the ArsTechnica folk have not found a way to record the audio of a game… apparently it is not as easy as you might think, to record OpenGL games. Programs like FFMPEG and VLC are able to record (parts of) your desktop but it is cumbersome and also does not deliver high-quality video with properly synced audio. These programs are not capable of intercepting OpenGL renders either, which limits their use.
So I went looking… and came across GLC, an ALSA & OpenGL recording software for Linux which was inspired by Fraps and Yukon, but it seems mostly abandoned by its author. Then there also is SimpleScreenRecorder, a relatively new piece of work by Maarten Baert. The program uses FFMPEG’s codecs to allow you to record audio and video into any format supported by the locally installed version of ffmpeg. It supports the recording of ALSA sound sources (think of a microphone). The word “simple” in its name only characterizes the ease-of-use, not the featureset! And it has a Qt-based GUI which nicely blends into my KDE desktop. By means of an OpenGL injection library it also supports direct recording of OpenGL renders (read: games). That should produce superior videos compared to merely recording the desktop window (because that produces lower frame rate videos or lower quality).

Unfortunately it turned out that SimpleScreenRecorder was not capable of recording my Slackware desktop’s sound, and therefore game videos are silent.
That is a show stopper… apparently you need a sound server like PulseAudio in order to record the audio as well. I am not prepared to install PulseAudio on Slackware – as you are well aware, this is a personal issue I have with the PA author and the way he writes code. So I investigated further, and found out that the unreleased GIT sources of SimpleScreenRecorder support JACK as a new sound source next to ALSA (and PulseAudio). I built the program from its GIT sources and then went on to learn about JACK Audio Connection Kit. I knew that JACK is primarily used by audio professionals and musicians because of its low-latency core design. But as it goes with versatile programs, it is inherently difficult to grasp its concepts and complex to configure. But I persevered and ultimately found a way to configure JACK on my desktop, and reconfigure my ALSA setup so that all the programs that I use can still emit sound, and SimpleScreenRecorder is now capable of recording video and audio! I put a demo video online which I recorded for the intro sequence from the Metro: Last Light game.

As you can see, the game stutters a bit, but that is not caused by the recording software – it’s my desktop PC which is just not fast enough for the game.

ssr_qtui

My next post will be about how I built and configured JACK, and what I had to change in my ALSA configuration so that for instance Steam games (using SDL for audio) and MineCraft (using OpenAL for audio) would still make sounds.

In the meantime, if you want to try SimpleScreenRecorder, there’s a couple of dependencies you need to install as well. SimpleScreenRecorder was built against ffmpeg (version 2.1 to be precise – please note that upgrades of ffmpeg will usually break a lot of applications that depend on it due to a change in library versions). Also, the package which I released has been built against jack – even if you do not plan on using it, you’ll have to install it… or you can rebuild SimpleScreenRecorder yourself.
If you want to use SimpleScreenRecorder to record 32-bit OpenGL programs (Steam games, WINE based games) and are running a 64-bit Slackware, it will have to be a multilib system and you will have to use the “convertpkg-compat32″ script (part of my compat32-tools package) to convert and install the 32-bits “compat32” versions of the simplescreenrecorder, ffmpeg and jack packages as well as the 64-bit versions.
If you want to try and record a Steam game without the Steam windows being visible (those are also rendered in OpenGL), you’ll definitely have to read these instructions: http://www.maartenbaert.be/simplescreenrecorder/recording-steam-games/#native-steam-for-linux because currently it involves some manual tweaking to get this working (I expect that this will get easier in time). Judging by his Wiki, Maarten is responsive to the users of his program and is able to write meaningful documentation.

Get packages (and sources) here:

Have fun! Eric

© 2024 Alien Pastures

Theme by Anders Noren — Up ↑