Setting up Jack Audio in Slackware

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):

December updates and a Christmas goodie for cable geeks

The silent treatment?

Hi there.
I know I have not been posting a lot the past few months. Sorry for that, really.
The last quarter is always a busy time at work and especially so during Corona; my mother fell ill; I sort of crashed when I ran out of energy; and it was a lot of work to clean up shop after my Plasma5 ‘ktown’ first got adopted as Slackware ‘vtown’ in testing and a bit later replaced the old KDE4 in the core distro. Lots of package recompilations and upgrades to work with the newer stuff in Slackware.

I also worked on (finally) migrating the old ‘bear’ server which was hosted in France, to a newer and more powerful server running in an Amsterdam Data Center. The new server ‘martin’ was mostly ready when I thought, let’s reboot ‘bear’ after applying the latest Slackware security fixes. And then it did not come back up… that was not a comfortable moment, since ‘bear’ not only hosts my own package and git repositories, but also The Slack Docs Wiki, the Slack Docs mailing lists, my own personal Wiki and some private family sites. I opened a support ticket and it turned out that the hard drive had crashed and all data on it were irrecoverable.
Luckily I had just finished making a set of backups and right before that fateful reboot, had discovered that my backup scripts omitted part of the server data… which I had also fixed just in time before  that crash.
It took some additional energy to get the services up and running on ‘martin’ again as soon as possible. I had made some new designs for the new server OS configuration and the new configs were un-tested… I hope not too many people noticed the partial down during the second half of November.
The new server runs fine now, has more disk space especially, so I can finally host the full history of Slackware releases and also the DAW and CINNAMON Live ISO images for which there was no room on ‘bear’.
Thanks again to those people who send me money un a regular basis so that I can pay the monthly rent of ‘martin’!

Despite that stress I have been enjoying myself still, just not in the spotlights. The semi-sudden switch in Slackware from KDE4 to Plasma5 and refreshing its XFCE Desktop had some consequences for my liveslak project. It took some time to work out a new optimal package set for the small XFCE image, and in particular the DAW Live image which is based on a bare Plasma5 Desktop needed attention to make it tick again.

So what’s new in Slackware DAW Live?

Remember: DAW = Digital Audio Workstation.
Read my original article documenting the research into a comprehensive collection of musician/producer oriented free and open source software, and a follow-up article on how to transform a Slackware system into a powerful Digital Audio Workstation.

Art work

I asked you in a previous post to come up with ideas for artwork to use in my Slackware Digital Audio Workstation. Thanks for those who contributed graphics and ideas – all of that creativity has been preserved here on the blog.
I decided to use the image to the left of this paragraph – a Slackware ‘S’ with headphones – as the icon to use for the “Slackware Live DAW” submenu. Contributed by Daedra and slightly colored by me.

I needed a second icon as well, to represent the ‘face’ of the Live user account, and for that I picked one of the contributions from Bob Funk: a Slackware ‘S’ with a TRS jack. You’ll see this one when you boot up the ISO and are asked to login at the SDDM graphical session chooser.

More art work was contributed by Sceptical-C, a friend of mine who doubles as a DJ, musician and producer. His black and white photography are the basis for several Plasma5 wallpapers and one of his photographs is also used as the background in the login and lock screens.

DAW_base package

I decided to move the configuration  of the DAW Live OS’ realtime capabilities out of the liveslak scripts and into a new Slackware package. This package called “daw_base” can be installed on any Slackware computer (preferably Slackware-current with PAM). It configures the OS in such a way that a user who is a member of the Slackware “audio” group is allowed to start applications with real-time scheduling priority. You’ll need that if you want to prevent sound drop-outs (also called XRUNs) during performing, recording and mixing. Some more tweaks are being made, they are documented in the package’s README.1st file. This package also contains the Plasma5 wallpapers which are created from the original Sceptical-C black-and-white artwork.
The package creates a new sub-menu in “Applications > Multimedia” called “Slackware DAW” and collects all my DAW related software in there. The submenus in “Multimedia” for the X42 and LSP plugins are moved into the “Slackware DAW” menu to keep it all closely together. This is very similar to what DAW Live also contains. Just the word “Live” is not present in the name of that menu installed by ‘daw_base‘.

The daw_base package also installs a template file for Slackware’s package manager ‘slackpkg‘. The template called “daw” contains a list of all DAW related software in my package repository and it allows for an easy installation and maintenance of that software collection.

New additions to the musician’s toolkit

Several packages needed a recompilation after the recent Slackware upgrades that are related to the new requirements for XFCE and Plasma5. I used that opportunity to upgrade software to their latest versions instead of recompiling – like Ardour, Mixxx, Jamulus, Guitarix for instance. But I also looked into some new stuff, mostly because people asked me about it. Here they are:

Zrythm.
An intuitive digital audio workstation all in itself. It’s under heavy development and nearing a 1.0.0 release. It supports LV2 plugins, offers a high level of automation, and looks really good. Perhaps an alternative for those who feel Ardour’s learning curve is too steep.

VCV Rack.
VCV Rack by the VCV project is a software emulation of the Eurorack Modular Synthesizer.
The project’s mission statement contains this line which resonated with me: “… the principle behind modular synthesizers is identical to the UNIX philosophy, where stable, minimal modules working together are preferred to a monolithic platform controlled by a single vendor (like portable synthesizer keyboards)“.

A short intermezzo first. My first experience with modular synths was as part of the audience when attending a concert by Pere Ubu, 1981 in De Effenaar in EIndhoven. Alan Ravenstine handled a huge contraption full of patch wires that produced all sorts of weird and interesting sounds. It’s what gave Pere Ubu their uniquely distinctive sound. I read later that he worked with EML modular synthesizers a lot but at the time I didn’t know. Damn impressive, but I decided that industrial sounds were more to my liking. This was during the early rise of Electronic Body Music, and that got me hooked for a while. If you can find the documentary “I dream of WIres” I recommend you watch it. The web site http://idreamofwires.org/ is dedicated to documenting the history of electronic music. An excerpt of a little more than 20 minutes is freely available, it contains an interview with Pere Ubu synth players Alan Ravenstine and Robert Wheeler.

Anyway – back in May 2019, a blog comment by ‘Hank’ already referenced VCV Rack with a question whether I would perhaps consider it for inclusion to my DAW software collection. At the time, my focus was on other things and a modular synthesizer is not the easiest instrument to work with, so I let that pass. But some recent youtube footage sparked my interest and here is the result – a Christmas present of sorts for you: packages for VCV Rack, and three free and open source plugins that expand the collection of available modules in Rack: vcvrack, vcvrack-audible-instruments, vcvrack-befaco and vcvrack-bogaudio.

Note that my VCV Rack package ‘vcvrack‘ contains the Fundamental plugin already. The software is quite useless without it so I decided to bundle it, just like the dev’s binary distribution. It is the only plugin which is automatically loaded by VCV Rack. If you install any other plugin, you need to execute one manual command to add the plugin to your user-directory: this will create a symbolic link to the ZIP file containing the modules and Rack will then automatically find and unzip this plugin and make it available to you.

$ ln -s /usr/share/vcvrack/Pluginname.zip ~/.Rack/plugins-v1/

All ZIP files in the VCV Rack system directory (/usr/share/vcvrack/) are module plugins – this is the format for distributing them.

Here is a Youtube tutorial series that you can use as an introduction to modular synthesis and VCV Rack in particular:

Enjoy! Eric

Liveslak new features, DAW Live, OBS Studio, logo contest

I wanted to update you about a couple of my projects that I was able to spend time on, now that I took some time off of work. I need to distance myself from my day job every so often to prevent a burn-out and this time I am dangerously close.
I baked bread for the first time in years and it was well-received in the family. The result was a tasty sourdough bread using the wild yeast culture that I am keeping healthy for many years now, even if I had not used it for making bread for a long time. Although a while ago I did share some of the sourdough culture with a friend who is also into baking bread. Even a tiny bit of “starter” can jumpstart your career of baking 🙂 It’s a tedious task to raise a healthy culture of wild yeast and suitable bacteria that create good bread.

But I would like to focus more on liveslak, on my Digital Audio Workstation spin, and some new software for which I created packages.

The liveslak project received some interesting new features.
Most importantly, the hard disk installer of the Slackware Live Edition – called “setup2hd” – was expanded. In the past, it used to allow only the installation of the Live OS to your hard drive. But I received requests to also make it possible for setup2hd to install regular Slackware like the official installer does. It sounded like a good idea, and starting with liveslak release 1.3.7 the “setup2hd” program will let you choose from more package SOURCES than just the Live OS. In addition to the Live OS, you can now choose to install regular Slackware from a NFS, HTTP, FTP or Samba server. In other words, Slackware’s network install feature was added.
Why is this different from the setup program on the official Slackware ISO? Well, the most obvious improvement is that you are working in a graphical desktop environment (the Live OS). You can run the setup2hd hard disk installation in an X terminal while you keep doing other stuff like reading online materials or watching a video to pass the time. Moreover, you can install stable Slackware 14.2 from the Live OS. That means MMC and NVMe drives are supported during installation (which is something the official Slackware 14.2 installer does not provide for).
And to top it off, I am now also adding “setup2hd” to the small XFCE ISOs. Word of caution: the XFCE ISOs do not contain a “huge” kernel which means if you want to install the stripped-down XFCE OS to your hard drive, you will have to do a manual “chroot” after installation completes and before you reboot, to edit /etc/lilo.conf and add a section for the “generic” kernel. and then run the “lilo” command to make it stick. Hopefully the “liloconfig” command will learn how to do that for you, sometime soon. You can always perform a Slackware network installation from the XFCE Live OS of course!

The second new feature is the ability of liveslak to configure a custom background image for Plasma5-based Live OS. The custom image is used when generating the Live ISO, as the background for the SDDM login greeter, your desktop wallpaper, and for the lock-screen backdrop.
What I still want to achieve is adding similar functionality to the XFCE and Gnome based Live variants. The snag is that the configuration needs to be scriptable, i.e. when the “live” user logs in everything must already be in place and pre-configured. For Plasma5 that was not trivial to work out, and I have zero Gnome and XFCE scripted desktop configuration knowledge. Suggestions and code snippets are welcome.

My Digital Audio Workstation project, called Slackware Live DAW, received some updates as well. The blog article I link to describes the generic process to tune and tweak Slackware for use as a real-time audio workstation, but I used that knowledge together with a whole lot of useful audio and music software to create a Slackware “spin-off” if you want – building on a lean Slackware package set plus the core of KDE Plasma5.
Since Slackware Live DAW  is based on liveslak, it profited from improvements in that area too. Most notably the DAW Live ISO now comes with a nice dark black & white themed background – which is better on the eyes if you work on your musical project in a room with low ambient light intensity.

Created with GIMP

The other improvement, or enhancement if you will, is that I have collected all the DAW specific programs in their own submenu “Applications > Multimedia > Slackware Live DAW” and removed them from the “Multimedia” menu. This lets you focus on the audio workstation purpose of this Live OS by having all your tools in one place.
And of course, the “setup2hd” program allows you to install the Live OS to your hard drive. One caveat though: the installation will be pristine, meaning you will get all the packages but not the “liveslak” customizations installed. What you won’t get is: the nice wallpaper, the “Slackware Live DAV” submenu, the real-time tweaks to the Operating System and the pre-configured JackQtl. On my TODO is to create a way (perhaps a package) to apply all of these customizations easily afterwards. For now, best is to run the Live OS directly from a persistent USB stick. If you have a bit of patience and at least 8 GB of RAM, you can load the whole Live OS into RAM when it boots up, and use the USB persistence to write your updates to the USB stick while you work, using the liveslak boot parameter “toram=os“. Loading into RAM will take a few minutes but then you have a lightning fast DAW OS that runs completely in memory.

I created a short video to show the boot sequence, the wallpaper and the new submenu:

Now that I am writing about my DAW project, I also want to use the opportunity to ask you – my readers – to participate in a small contest. I am not good with graphical tools, but I would really like a couple of graphics:

  • a logo for Slackware DAW Live. Higher up on this page I used a generic “tux with headphones” image but I want something special for the project. A SVG file would be best but I will settle for a nice PNG.
  • a user icon for the live account. Currently all Slackware Live editions use the purple Slackware “S” icon , but I want an icon that reflects both Slackware and making music.

I welcome your submissions and will create an overview page with all of the graphics I receive. Ultimately I will select the ones I like most and use then in the liveslak project. So please do  not share copyrighted material.
I came up with the wallpaper image myself, and I asked a friend of mine, who is also a producer and a dee-jay, to supply some of his own black & white photography as wallpapers for Slackware Live DAW.

Some of the packages I created or updated lately

I usually update the blog when I have something to share about my high-profile packages like chromium, libreoffice, openjdk, vlc and the likes. But I add stuff to the repository from time to time that serves a specific purpose – either because someone I know requested a new package, or because I expand the list of available software for my DAW Live project. Here are a couple that I did not mention yet.

OBS Studio (formerly known as Open Broadcaster Software) is video recording and streaming software. It is sometimes referenced by people when they email me with requests to create a package for it. Working out the dependencies and packaging those is not trivial. I realized that I could use this myself (to create the above video of booting DAW Live), and have added it to my slackbuilds repository along with a dependency that was not in there yet: mbedtls. The other dependencies for OBS Studio were already in my repository: jack2, vlc  and x264.
I chose not to add “luajit” as yet another dependency. Luajit meant to add Lua scripting support, but OBS Studio already supports scripts via Python3. If anyone needs Lua as well, let me know. I also did not add the suggested “fdk-aac” encoder dependency for AAC audio since Slackware’s ffmpeg package also has an AAC encoder and OBS Studio will use that instead.
I realize that Patrick recently added Simple Screen Recorder (ssr) to Slackware-current but OBS Studio is more powerful and has a lot of features which make it particularly suited for people who stream their video recordings directly to sites like Twitch or Youtube.

Geonkick is “a synthesizer that can synthesize elements of percussion. The most basic examples are: kicks, snares, hit-hats, shakers, claps”. Unfa has a video up on Youtube in which he shows a bit of the interface and the percussion sounds you can create. I added this one to my DAW package list so you can use its functionality as a plugin in Ardour or as a standalone app.

 

QTractor? My DAW package list already contains Ardour and Audacity to use as your main application to record, mix and process music. They serve different purposes and audiences – Audacity is a multi-track recorder with nice post-processing capabilities, and for some people that is all they need when Ardour has a long learning curve.
Qtractor is yet another digital audio workstation tool. It is a multi-track sequencer for audio and MIDI, with a nice QT5 interface and extensive plugin support. I guess it is comparable to Ardour but less complex and therefore suited for somewhat less experienced musicians and producers.

And here is MuseE, another audio and MIDI multi-track sequencer with an interesting feature list and a QT5 interface. Similar to QTractor you can use MusE as a your DAW studio interface or use it to pre-process your MIDI tracks before importing them into Ardour, as shown in this video tutorial sequence by LibreMusicProduction.

It will be a matter of preference which of these programs you are going to use. They are all part of Slackware DAW Live so go ahead and try them out! The Slackware DAW Live ISO image can be found at https://martin.alienbase.nl/mirrors/slackware-live/pilot/ https://slackware.nl/slackware-live/latest/ and I recommend to copy it to a USB stick as a persistent Live OS, using the iso2usb.sh script.
If and when I manage to migrate slackware.nl to a bigger server I will be able to finally host it there along with the other liveslak stuff (Update 2020-Nov-15: I finally migrated to a new server and the old server died in the process, but not before I managed to save all important stuff).

Have fun! Eric

Sonic-Pi: live-coding music software now on Slackware

Here is a new program for inclusion into my DAW package collection. It is Sonic-Pi, a ‘code-based music creation and performance tool’ as its web site states. My DAW collection already features Supercollider, which at its core is a powerful audio synthesis engine, but it also features a graphical user interface which you can use for live-coding music. Sonic-Pi has similar capabilities but it is more intuitively accessible (compare it to vi and notepad for instance).
Therefore Sonic-Pi would be better suited for introducing people to the concept of creating music through writing code, and letting that music evolve during a live performance by updating on-the-fly the code which represents the audio synthesis.

Sam Aaron is the creator of Sonic-Pi and uses it as a musical instrument in its own right with his band. He did a TEDx talk about programming as performance a couple of years ago:

He explains how Sonic-Pi was conceived as an educational tool. By making a free and open-source program like Sonic-Pi available to schools (and it runs on the Raspberry Pi – now you know where the program got its name from), you will gently introduce young kids to the art of computer programming while at the same time infusing them with a love for music – because they will be able to create the music they like in no time.

Sonic-Pi uses the synthesis engine of Supercollider, which means that that has to be installed as well. Both Sonic-Pi and Supercollider use JACK to route the audio and let it come out of your speakers.
The graphical user interface allows easy access to a large collection of example code snippets, sound samples and synthesizer definitions, so you will be listening to music in a few seconds after starting the program – after which you can begin modifying that code and hear live what your programming does to the generated music. The GUI also contains a nice visualization of the music you are generating.

The software is usually distributed as an ‘appimage’ which simply bundles everything you need into an archive. This is not really Slackware-like, so I wrote a SlackBuild script which brings some order into the directory structure, removing a lot of redundant megabytes and creating a proper package with a nice menu item.

The liveslak scripts have been updated as well so that the next Slackware DAW Live will include Sonic-Pi.
If you use slackpkg you can download an updated template here: http://www.slackware.com/~alien/tools/templates/daw.template and use “slackpkg install-template daw” to have easy access to the full list of packages.

Get Sonic-Pi from https://slackware.nl/people/alien/slackbuilds/sonic-pi/ or https://slackware.uk/people/alien/slackbuilds/sonic-pi/ . Mind the dependencies!

Have fun! Eric

MIXXX: powerful DJ-ing software

Yesterday I watched a new video on Unfa’s Youtube channnel. He reviewed and demo-ed MIXXX.

Mixxx is a powerful and free (open source) DJ program which allows you perform a live set with up to 4 virtual decks and optionally stream it to a broadcasting server. Common effects like echo, flanger, reverb, bitcrusher are available, and through its LV2 plugin interface you can use many more external effects to spice up your set.
Its master sync feature ensures that the music primed in all your decks stays locked to the beat. You can control pitch and key, or loop a stretch of audio. Quantize your cues and loops so that they start right on the beat all the time. And so on – and all of that with an attractive skinnable user interface.

You can plug in a MIDI controller and map its buttons/knobs/sliders to operate the Mixxx user interface so that you do not have to use your computer’s mouse & keyboard to cue, mangle and cross-fade the audio. There’s actually a lot of presets you can load for the most well-known MIDI controllers like the Novation LaunchPad Mini.

If the JACK daemon is running you can connect Mixxx to it, but it will perform just fine with ALSA as well.

This was a piece of software which was missing from my DAW package collection. Therefore I created packages for mixxx and its dependencies and added them to the repository. The liveslak scripts have been updated as well so that the next Slackware DAW Live will include Mixxx for you to try out.
If you use slackpkg you can download an updated template here: http://www.slackware.com/~alien/tools/templates/daw.template and use “slackpkg install-template daw” to have easy access to the full list of packages.

Have fun! Eric