Alien Pastures

My thoughts on Slackware, life and everything

Category: Music (Page 1 of 4)

Slackware Cloud Server Series, Episode 11: Jukebox Audio Streaming

April 3, 2026 / / 7 Comments

I am an avid music lover. My tastes are eclectic; I enjoy electronic, industrial, punk, new wave, reggae and dub but also baroque and classical music. I used to tape my own music cassettes when I was young, sharing my mixes with friends. I have hundreds of vinyl albums and at many more compact discs. But technology kept evolving and I switched to MP3 files that I could store on my computer and play using VideoLAN VLC for instance. But I also want to be able to just listen to my music in the living room without operating a laptop and for that, I setup a streaming server that acts as a jukebox, continuously picking random songs from my collection and playing them from a queue that never empties. In the living room I have a Denon AVR-X2300W which can pick up the network stream.
I have been running this audio streaming server for decades. First using OTTO, then Calliope and then coming back to OTTO after it had re-invented itself. But Calliope and OTTO are no longer maintained and  quite tricky to setup in the first place. I am not looking forward to migrate this unsupported setup to Slackware 15.1 when that gets released and I move my server to it.

I went on a search for a modern, maintained and open source alternative for my OTTO server.
I have actually setup Mopidy with Pibox extension to get the jukebox functionality. Recompiling Slackware’s gst-plugins-good package against libshout enables the libgstshout2.so library which gives us ‘shout2send‘ which then streams audio from Mopidy to my Icecast server. Setting it all up was not trivial and I did not like how the Pibox extension handled the queue autofill. I went on with my search for a good OTTO alternative and I hope I found it.

In this episode of Slackware Cloud Server I will show you how to stream your personal MP3 collection via Icecast using the open source platform AzuraCast. A worthy addition to your Slackware Cloud Server as as service to yourself, friends, family or even your local community.

Check out the list below which shows past, present and future episodes in my Slackware Cloud Server series. If the article has already been written you’ll be able to click on the subject.
The first episode also contains an introduction with some more detail about what you can expect.

Introduction


What is AzuraCast?

AzuraCast is a self-hosted, all-in-one web radio management suite consisting of multiple independent but co-operating components:

  • Liquidsoap
    This is the automation engine that fills your play queue, handles scheduling and song rotation, and feeds the stream source, re-encoding if needed.
  • Icecast-KH
    A maintained fork of Icecast that handles the actual audio streaming to listeners.
  • A PHP/Vue web application
    The management interface where you control everything: upload music, browse your library, configure playlists, handle listener requests, check analytics.
  • MariaDB server
    Stores the song metadata, play history and playlists.
  • Redis
    Runtime memory store for the session cache and queue state.

We will be running the whole stack in Docker, making it self-contained regardless of your Slackware version. The local directory tree containing your music library will be bind-mounted inside the Docker container.
We will setup the Apache HTTP server as a reverse proxy so that we can access the Management UI securely via HTTPS. We will also proxy the Icecast stream on a standard port so that listeners would not have to connect to your Icecast mount point via e.g. ‘http://yourserver:8000/radio.mp3’ but rather via a regular URL like ‘https://yourserver/yourchannel’.
Any player that speaks Icecast like VLC, mpv, foobar2000, mpc, also every browser and surely many more will be able to playback your music.

What makes AzuraCast the right solution?

When searching for a replacement I had several requirements in mind that a new program should meet. AzuraCast ticks more boxes than any of the other solutions I encountered and/or tested:

  • Should be able to handle tens of thousands of songs effortlessly
    Azuracast indexes my library in a MariaDB database. 50 000+ tracks is a documented use-case.
    I can tell you from experience that it takes a day or two to get 50K songs indexed however.
  • Continuously fills the play queue (it must never be empty)
    The Liquidsoap AutoDJ has configurable rotation and fills the queue automatically.
  • Manual song requests should be added to the head of queue
    AzuraCast has a ‘Listener Requests’ feature. It’s available via its web UI but also as a REST API.
    It should be possible to configure the AutoDJ in such a way that user requests are immediately placed at the head of the queue, unfortunately I have not yet found out how. Because the AutoDJ  pushes the tracks its queue to the Icecast server immediately, any user requests will be scheduled after that queue, not before it. I need to keep the queue length (which is configurable) to a minimum value of 2 to make the experience acceptable.
  • Web-based management interface
    AzuraCast comes with a full-featured, mobile-friendly web UI with lots of analytics, logging and debugging tools.
  • Auto-detect or manually re-scan for new music files
    It can do both: it runs an internal background task (with configurable interval) to scan for new music regularly, but there’s also a command-line option to re-scan your entire music collection.
  • Stream output via Icecast protocol
    Icecast-KH is the native output; every mount point is a standard Icecast stream.

Architecture overview

Preamble

This section describes the technical details of our setup, as well as the things which you should have prepared before trying to implement the instructions in this article.

Web Hosts

For the sake of this instruction, I will use the hostname “https://radio.darkstar.lan” as your landing page for AzuraCast.
The URL for the Icecast stream will be “https://radio.darkstar.lan/lowlands“.

Setting up your domain (which will hopefully be something else than “darkstar.lan”…) with new hostnames and then setting up web servers for the hostnames in that domain is an exercise left to the reader. Before continuing, please ensure that your equivalent for the following host has a web server running. It doesn’t have to serve any content yet but we will add some blocks of configuration to the VirtualHost definition during the steps outlined in the remainder of this article:

  • radio.darkstar.lan

Using a  Let’s Encrypt SSL certificate to provide encrypted connections (HTTPS) to your webserver is documented in an earlier blog article.

Note that I am talking about webserver “hosts” but in fact, all of these are just virtual webservers running on the same machine, at the same IP address, served by the same Apache httpd program, but with different DNS entries. There is no need at all for multiple computers when setting up your Slackware Cloud server.

Docker network

  • We assign a Docker network segment to our AzuraCast container: 172.24.0.0/24 and call it “azuracast.lan“

File Locations

  • The Docker configuration goes into: /usr/local/docker-azuracast/
  • The data generated by the AzuraCast server goes into: /opt/dockerfiles/azuracast/

Port numbers

Since everything runs in a Docker container, all services listen at the localhost address 127.0.0.1.

  • AzuraCast Web UI in Docker: listens at TCP port 81
  • Icecast mount points: we will open two (for two audio streams) that listen at TCP ports 8001 and 8002

Station name

  • Our Icecast Radio Station will be called: Alien Pastures Radio
  • Inside Azuracast (primarily used to create the directory to mount the media) this name is trivially translated to: alien_pastures_radio

Installation

AzuraCast’s recommended installation method uses a helper script that downloads the Docker Compose configuration, fires the container, and allows for post-installation maintenance and management. We are not going to use that.
Still, in order for you to be able to switch effortlessly to the AzureCast officially suggested Docker setup, I will follow their recommendations to add all of the customization into a separate ‘override‘ file for Docker Compose.

Docker network

Create the network using the following command:

docker network create \
  --driver=bridge \
  --subnet=172.24.0.0/24 --gateway=172.24.0.1 \
  azuracast.lan

Docker’s gateway address in any network segment will always have the “1” number at the end.
Select a yet unused network range for this subnet. You can find out about the subnets which are already defined for Docker by running this command:

# ip route |grep -E '(docker|br-)'

The ‘azuracast.lan‘ network you created will be represented in the AzuraCastdocker-compose.yml file with the following code block:

networks:
  azuracast.lan:
    external: true
Directories

Create a directory structure for AzuraCast as a Docker container. We’ll change ownership of two of those directories: backups and storage. The UID/GID numbers I use (shown in bold green) must correspond to the values you define for AZURACAST_PUID and AZURACAST_PGID in the ‘.env‘ file you will create in the next step. If you omit that ‘chown‘ step, AzuraCast will not be able to save Station information nor will it be able to create backups of its SQL server.

# mkdir -p /opt/dockerfiles/azuracast/{backups,db_data,stations,storage}
# chown 1000:1000 /opt/dockerfiles/azuracast/{backups,stations}
# mkdir -p /usr/local/docker-azuracast
# cd /usr/local/docker-azuracast
Configuration files

Download an example Docker environment file and store it under the name ‘.env‘ from https://raw.githubusercontent.com/AzuraCast/AzuraCast/stable/sample.env

Note that I download all files from the ‘stable’ branch of the AzuraCast git repository. You could also try the ‘main’ branch if you like to live on the edge.

The container ships its own internal Nginx proxy that also takes care of the SSL certificates, but I want to use my own host server’s Apache HTTP daemon to take care of the reverse-proxying. All you need to do to disable Nginx is to change the “AZURACAST_HTTPS_PORT” value from the default “433” to something else… and of course because port “443” is already in use on our server.
Likewise, we need to change “AZURACAST_HTTP_PORT” from the default value of “80” because that’s where our own Apache server is listening next to port 443.
After making the necessary changes we end up with an ‘.env‘ file containing (use your own values for the green example values if you want that):

# Make it easier to manage the project in Docker Compose:
COMPOSE_PROJECT_NAME=azuracast
# Define network ports:
AZURACAST_HTTP_PORT=81
AZURACAST_HTTPS_PORT=8412
AZURACAST_SFTP_PORT=2022
# We stick to the 'stable' channel instead of 'latest'
AZURACAST_VERSION="stable"
# If you start docker as your own user instead of root, change these to your own UID/GID
AZURACAST_PUID=1000
AZURACAST_PGID=1000

The ‘.env‘ file above is a configuration file which is read and used by the Docker daemon to setup the container. We are now going to create a second configuration file called ‘azuracast.env‘, containing the data that AzuraCast itself needs in order to function. Get the example file from https://raw.githubusercontent.com/AzuraCast/AzuraCast/stable/azuracast.sample.env and tailor it to your needs.
In the end ‘azuracast.env‘ should look like this (lots of comments and default values removed):

APPLICATION_ENV=production
COMPOSER_PLUGIN_MODE=false
AUTO_ASSIGN_PORT_MIN=8000
AUTO_ASSIGN_PORT_MAX=8001
SHOW_DETAILED_ERRORS=false
MYSQL_PASSWORD=azur4c457
MYSQL_RANDOM_ROOT_PASSWORD=yes

The two values in bold green for the lower and upper range of the Icecast ports correspond with the values I defined earlier in the ‘Preamble‘ section. The range of two ports means that this setup supports two independent Icecast streams.

The docker-compose.yml file

Get the ‘docker-compose.yml‘ file from https://raw.githubusercontent.com/AzuraCast/AzuraCast/stable/docker-compose.sample.yml
After removing the sections I don’t need (they enable the official “docker.sh” script to perform maintenance and upgrades) the file it will look like this:

# If you need to customize this file, you can create a new file named:
# docker-compose.override.yml
# with any changes you need to make.
#
name: azuracast

services:
  web:
    container_name: azuracast
    image: "ghcr.io/azuracast/azuracast:${AZURACAST_VERSION:-latest}"
    # Want to customize the HTTP/S ports? Follow the instructions here:
    # https://www.azuracast.com/docs/administration/docker/#using-non-standard-ports
    ports:
      - '${AZURACAST_HTTP_PORT:-80}:${AZURACAST_HTTP_PORT:-80}'
      - '${AZURACAST_HTTPS_PORT:-443}:${AZURACAST_HTTPS_PORT:-443}'
      - '${AZURACAST_SFTP_PORT:-2022}:${AZURACAST_SFTP_PORT:-2022}'
      - '8000-8001:8000-8001'
    env_file:
      - azuracast.env
      - .env
    volumes:
      - station_data:/var/azuracast/stations
      - backups:/var/azuracast/backups
      - db_data:/var/lib/mysql
      - www_uploads:/var/azuracast/storage/uploads
      - shoutcast2_install:/var/azuracast/storage/shoutcast2
      - stereo_tool_install:/var/azuracast/storage/stereo_tool
      - rsas_install:/var/azuracast/storage/rsas
      - geolite_install:/var/azuracast/storage/geoip
      - sftpgo_data:/var/azuracast/storage/sftpgo
      - acme:/var/azuracast/storage/acme
    networks:
      - azuracast.lan
    restart: unless-stopped
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    logging:
      options:
        max-size: "1m"
        max-file: "5"

volumes:
  db_data: { }
  acme: { }
  shoutcast2_install: { }
  stereo_tool_install: { }
  rsas_install: { }
  geolite_install: { }
  sftpgo_data: { }
  station_data: { }
  www_uploads: { }
  backups: { }

networks:
  azuracast.lan:
    external: true

This docker-compose.yml file defines a number of Docker Volumes.  Don’t mind those, AzuraCast needs them but we don’t. We will mount a local directory containing our music library into AzuraCast container later and  make sure that the Station data is all written to a host directory as well.

Note:
If you want, you can use the downloaded original of ‘docker-compose.yml’ instead of my truncated version above. There’s almost no difference in execution or functionality (except for the custom network and the TCP port range it opens for the hundreds of potential streaming channels), but the original file is much too large to copy into this article..

You need to be aware that the downloaded official Docker Compose configuration file opens a bunch of TCP ports in the range of 8000 to 8500. That’s one TCP port per music stream you want to create, so the default configuration allows for a total of 500 different streams or ‘stations‘. I only run a few streams myself, and I used that in the above modification which opens only 2 ports.You may want to increase the number of possible streams on one AzuraCast instance. You can do that by editing the ‘docker-compose.yml‘ file, but since we’re going to use it anyway further down, I want to draw your attention to the option of creating a new file named ‘docker-compose.override.yml‘ in the same directory next to your docker-compose.yml and .env files.

I will show you how you can increase the Icecast listen ports from 2 to a total of 100 ports aka audio streams. You can modify the port range in this file to meet your needs, such as expanding the range to port 8500 instead of 8099.
Let’s also add an override  for the Station data storage. We want to use a local directory instead of a number of Docker volumes. To the ‘docker-compose.override.yml‘ file, add a ‘web‘ service just like in the actual Docker Compose file above, and then add a ‘ports‘ and a  ‘volumes‘ section so that the file looks like this:

services:
  web:
    ## OPTIONALLY: Add more ports, each port supports one radio station:
    #ports:
    #  - "8002-8099:8002-8099"
    # Store all Station data on the host:
    volumes:
      - /opt/dockerfiles/azuracast/stations:/var/azuracast/stations
      - /opt/dockeriles/azuracast/backups:/var/azuracast/backups
      - /opt/dockerfiles/azuracast/db_data:/var/lib/mysql
      - /opt/dockerfiles/azuracast/storage:/var/azuracast/storage

You will probably have noticed that the host directories (the paths to the left of the ‘:’ colon) are the same directories that we manually created in an earlier step.

Ready for lift-off!

We have not yet added any audio library to the Docker configuration. That is because we don’t have all the required information yet, and the missing piece needs to be arranged from within AzuraCast. So let’s start it!
When you start the container for the first time, it will take a few minutes because Docker will be downloading several hundred megabytes of container layers. Subsequent updates will be much faster:

# cd /usr/local/docker-azuracast
# docker-compose up -d
# docker-compose logs -f

AzuraCast is implemented as a single Docker image which contains all the functionality (streaming server, web-UI, database etc). Historical releases used separate Docker containers for the various components of the streaming platform. This single container implementation means for instance that the internal MariaDB database is not exposed to the host at all, therefore the password for the “azuracast” database user does not need to change from the default in the configuration file.
Still, AzuraCast automatically generates a random password for the MariaDB ‘root’ user upon the first database spin-up. This password will only be visible in the container’s logs upon that first startup so be sure to look there and write it down (look for the string “GENERATED ROOT PASSWORD“). Alternatively you can set “MYSQL_RANDOM_ROOT_PASSWORD=no” in the file ‘azuracast.env‘ and then add an extra line defining “MYSQL_ROOT_PASSWORD=your_secret_dbroot_password“.

Note:
Possibly the MYSQL_ROOT_PASSWORD variable needs to be called MARIADB_ROOT_PASSWORD

Initial web user-interface setup

We need to take some necessary steps to ensure that we can complete our Docker configuration by adding a media library.

Upon the very first startup, AzuraCast will present you its Management Interface, where we will set a Station Name for the streaming server. The Station Name is what AzuraCast uses as its internal directory. For example, if the station is “Alien Pastures Radio“, the directory used inside the container will typically be “alien_pastures_radio“.

Open a browser on your host computer (the Cloud Server) and navigate to http://localhost:81/. Since we have not yet configured a reverse proxy, there’s no other way than to perform these initialization steps on the host.
You’ll be presented with the AzuraCast setup wizard that allows to:

  1. Enter your email address to create your administrator account
    Choose a strong password; this is the master key to your station.
  2. Create your first Station
    Give it a memorable name (for instance “Alien Pastures Radio“), choose your streaming format (MP3 at 192 kbit/s is a reasonable starting point), and note the station’s “short name” that AzuraCast generates (which would be “alien_pastures_radio” in this example). This is the string you need for the ‘docker-compose.override.yml‘ later on.
  3. Set your time zone
    This is relevant for scheduled playlists and analytics.

After completing the steps in the wizard you end up on the main station management page (the screenshot was taken after I mounted my local music library, added that to a new playlist and connected the playlist to the Station).

Mount your existing music library

This is the most important configuration step. AzuraCast lives inside Docker, but your big MP3 collection lives on the host. You need to tell Docker to make that directory visible inside the container as a “bind mount”.

At this point we will use the station’s internal directory name which you wrote down when  creating your station through the web UI in the previous section. Using the station name, create an override file name ‘docker-compose.override.yml‘ (or rather, merge it into the file which you created in an earlier step):

services:
  web:
    volumes:
      - /your/actual/path/to/mp3s:/var/azuracast/stations/alien_pastures_radio/media/remote/mp3:ro

Replace `/your/actual/path/to/mp3s` with the real path on your host (e.g. `/data/music`) and `alien_pastures_radio` with your actual station directory name. You’ll notice the “:ro” at the end of the internal directory. This means, that your media library is going to be mounted read-only.

Apply the change:

# cd /usr/local/docker-azuracast ; docker compose down ; docker compose up -d

Note #1:
If your music is spread across multiple directories, you can add multiple volume entries, each mounted under a different subdirectory of the station’s media path. AzuraCast will index all of them.

Note #2:
If you have symlinks inside of your media directory, AzuraCast will choke on them because AzuraCast’s filesystem abstraction library (Flysystem) does not support them. What you can do instead is remove the symlink and create a bind-mount in its place

Note #3:
If you do not want AzuraCast to edit your media files, the recommended way is to mount your files one directory deeper than the media directory and bind-mount that instead.
As in the example I show above, you could mount the container’s internal directory ‘/var/azuracast/stations/alien_pastures_radio/media/remote/mp3′ as a read-only volume. That way AzuraCast can still use the media storage location to store cached metadata about the files, but your host filesystem can remain a read-only mount.
As for whether AzureCast will actually write to media files: only when a user edits the metadata via the web UI. Those changes are written back to the file to ensure they persist, since most users expect that to be the case when editing tracks in the media editor. If you mount the filesystem as read-only though, it’ll just quietly fail that process but will still save metadata changes to its database.

Configure the AutoDJ (auto-queue)

The AutoDJ is Liquidsoap, and its most important configuration is the playlist.
A playlist in AzuraCast is not a fixed list of songs — it is a source from which Liquidsoap draws tracks to fill the queue. The simplest configuration is a single playlist pointed at your entire library, set to shuffle ad infinitum.

Step 1: create a playlist for your Station

Navigate to ‘System Administration > Stations > [Your Station] > Manage > Playlists > Add Playlist‘:

  • Name: “My Library” (or whatever name you prefer)
  • Type: ‘Standard Playlist‘
  • Source: ‘Song-based‘
  • Playlist type: ‘General rotation‘
  • Song Playback Order: ‘Random‘
  • Weight: ‘1‘
  • Click ‘Save Changes‘

The “Song-based” source is key. It automatically includes every song in your media directory tree, with no manual maintenance required. You can keep adding music to your directory on the host, and once AzuraCast’s internal media scanner task executes, the new tracks become available to the AutoDJ.
We do of course still need to add media to this empty playlist. That’s what the next step will take care of.

Step 2: Connect your media to the Playlist you just created

Go to ‘System Administration > Stations > [Your Station] > Manage > Media > Music Files‘

  • Select the media directory/directories which you bind-mounted into your Docker container.
  • Click on ‘Playlists‘ and select ‘My Library‘ (or whatever name you gave it)
  • Click ‘Save‘.
Step 3: Enable the AutoDJ

Go to  ‘Stations > [Your Station] > Edit > AutoDJ‘:

  • AutoDJ Service: ‘Use LiquidSoap on this server’ is checked
  • Crossfade Method: ‘Smart Mode‘
  • Click ‘Save Changes’

Within a few seconds Liquidsoap will start filling the queue and the stream will begin playing.
You can come back here later and experiment with the Audio Processing section to improve the listener’s experience.

Enable listener requests

The listener request feature is how you can manually perform queue management in those cases that you want to override the AutoDJ.
When a request is submitted, AzuraCast inserts that track as the next-to-play item,  ideally at the head of the randomized play queue which is maintained by the AutoDJ (but how to place the request at the actual head  is the final puzzle piece I cannot yet figure out).

To enable it, go to ‘Stations > [Your Station] > Edit‘

  • Under the ‘Profile‘ section,  select ‘Enable Public Pages‘
  • Under the ‘Song Requests‘ section, check ‘Allow Song Requests‘
  • Optionally set ‘Minimum Time Between Requests‘ to prevent the queue from being flooded
  • Click ‘Save Changes‘

Requests can be submitted in two ways:

  1. Via the public web page:
    AzuraCast generates a public-facing player page at ‘http://radio.darkstar.lan/public/alien_pastures_radio‘. This includes a search box that lets anyone (or just you) find a song and click “Request“.
  2. Via the ‘REST API’ (useful for automation or in case you want to write your own front-end):
    Use this curl commandline to search for a song (replace STATION_ID with your Station’s numerical ID. Your first Station has an ID of “1“). You can also find your station’s numeric ID in the URL when you’re on the station’s dashboard page.
    Note that this will return a long list of all your audio files in JSON format!
$ curl -s "http://radio.darkstar.lan/api/station/STATION_ID/requests" | python3 -m json.tool

Submit a specific request (replace SONG_ID with the numeric ID from the search results):

$ curl -X POST "http://radio.darkstar.lan/api/station/1/request/SONG_ID"

The full API documentation is available at ‘http://radio.darkstar.lan/api‘.

The Icecast output URL

AzuraCast automatically creates an Icecast mount point when you create a station. By default it will be accessible at: http://127.0.0.1:8001/radio.mp3

To change the default mount point name “radio.mp3” into something else, go to ‘System Administration > Stations > [Your Station] > Manage > Broadcasting (in the left sidebar) > Mount Points‘ and change the name there. As an example, we change it to “lowlands“. The “.mp3” extension is not needed at all.
To verify, go to ‘System Administration > Stations > [Your Station] > Manage > Overview (in the left sidebar)‘. In the “Streams‘ section of the overview you’ll see the mount points that Liquidsoap is publishing to Icecast, along with the listener count and current playing track.

Put it to the test

To listen to your new streaming server from the command line, use any program that supports the Icecast protocol: mpv, mplayer, vlc, mpc (if you want to feed the Icecast stream back into an MPD instance) etc:

$ mpv http://127.0.0.1:8001/lowlands

It works! Time to make this stream available outside of your host server and let family and friends enjoy your shiny new music station.

Apache reverse proxy (https)

Especially if your server is headless, you definitely want to manage AzuraCast over HTTPS using a normal URL instead of the localhost address. You may also want to expose the audio stream on port 443 instead of 8001 so that it will pass any company firewall with ease. To achieve this we turn again to our trustworthy Apache HTTP server and setup a reverse proxy.

The flow is as follows: the user connects to the reverse proxy using HTTPS (encrypted connection) and the reverse proxy connects to the AzuraCast Docker container on the client’s behalf. Traffic between the reverse proxy (Apache httpd in our case) and the AzuraCast Docker container is un-encrypted and happens on the loopback address.
A reverse proxy is capable of handling many simultaneous connections and can be configured to offer SSL-encrypted connections to the remote users even when the backend can only communicate over clear-text un-encrypted connections.

Add the following reverse proxy lines to your VirtualHost definition of the “https://radio.darkstar.lan” web site configuration and restart httpd:

# ---
# Required modules:
# mod_proxy, mod_ssl, proxy_wstunnel, http2, headers, remoteip

# No caching
Header set Cache-Control "max-age=1, no-control"

# Proxy configuration
<Proxy *>
    Allow from all
    Require all granted
</Proxy>

ProxyRequests Off
ProxyVia on
ProxyAddHeaders On
ProxyPreserveHost On
ProxyTimeout 900

# SSL configuration
<IfModule mod_ssl.c>
    SSLProxyEngine on
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
</IfModule>

# Allow access to everyone
<Location />
    Allow from all
    Require all granted
</Location>

# Letsencrypt places a file in this folder when updating/verifying certs.
# This line will tell apache to not to use the proxy for this folder:
ProxyPass /.well-known !

# Reverse proxy for the Web UI at http(s)://radio.darkstar.lan/
ProxyPass / http://127.0.0.1:81/
ProxyPassReverse / http://127.0.0.1:81/

# And the reverse proxy for the Icecast stream playing at http(s)://radio.darkstar.lan/lowlands
<Location /lowlands>
    ProxyPass http://127.0.0.1:8001/lowlands
    ProxyPassReverse http://127.0.0.1:8001/lowlands
</Location>

# AzuraCast requires a WebSocket proxy
RewriteEngine on
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule ^/?(.*) "ws://127.0.0.1:81/$1" [P,L]

# ---

If you want to make your non-encrypted web address http://radio.darkstar.lan redirect automatically to the encrypted ‘https://‘ variant, be sure to add this block to its VirtualHost definition to ensure that Letsencrypt can still access your server’s challenge file via an un-encrypted connection:

<If "%{REQUEST_URI} !~ m#/\.well-known/acme-challenge/#">
    Redirect permanent / https://radio.darkstar.lan/
</If>

The hostname and TCP port numbers shown in bold green are defined elsewhere in this article, they should stay matching when you decide to use a different hostname and port numbers.

Test and reload the Apache webserver configuration as follows:

# apachectl configtest
# apachectl graceful

MariaDB backups

The Web User-Interface of AzuraCast allows you to schedule regular backups of the SQL database which stores meta information about your Radio Station and media:
Go to ‘Administration > System Maintenance > Backups > Autiomatic Backups > Configure‘:

  • Check “Run Automatic Nightly Backups“
  • Check “Exclude Media from Backup“
  • Configure a time of the day, the archive format and the storage location (the default path in the dropdown is OK).
  • Click ‘Save Changes‘

Backup archives will be stored in the /opt/dockerfiles/azuracast/backups directory.
You can also manually backup the AzuraCast database and configuration with the following command:

# cd /usr/local/docker-azuracast
# docker compose exec web azuracast_cli backup --exclude-media /var/azuracast/backups/my-azuracast-backup.zip

This will create the backup ZIP file in your host’s local directory /opt/dockerfiles/azuracast/backups/.

Troubleshooting

The stream is silent / Liquidsoap is not playing

Check that your playlist has the AutoDJ enabled and that the mounted directory actually contains indexed files.

  • Change to the docker directory:
    # cd /usr/local/docker-azuracast
  • Check Liquidsoap logs:
    # docker compose logs | grep -i liquidsoap | tail -50
  • Verify the media directory is visible inside the container:
    # docker compose exec web ls -la /var/azuracast/stations/alien_pastures_radio/media/remote/mp3/

AzuraCast cannot read my MP3 files

File ownership matters. The AzuraCast Docker container runs as UID 1000 by default. If your host music files are owned by a different UID, make sure that the user account inside the container can read them.
Fix this by either:

  • Make files world-readable
    # chmod -R o+r /your/actual/path/to/mp3s
  • Or: change the container’s UID to match your host user.  In the ‘.env’ file that lives next to ‘docker-compose.yml’ you will find the below two lines. Change the UID number from 1000 to that of your own user on the host:
    AZURACAST_PUID=1000
    AZURACAST_PGID=1000

Then restart the Docker stack.

The web UI shows “0 files” after mounting

If you mounted the directory after the initial station creation but before a rescan, trigger a manual rescan:

# cd /usr/local/docker-azuracast
# docker compose exec web azuracast_cli azuracast:media:reprocess

The above command triggers a rescan for all Stations. If you want to trigger the rescan only for your own Station, run this instead:

# docker compose exec web azuracast_cli azuracast:media:reprocess alien_pastures_radio

You can also start the rescan process from the User Interface.
Go to ‘System Administration > Stations > [Your Station] > Manage > Media > Music Files‘:

  • Select “remote” or whatever root directory your media library shows
  • Click ‘More > Reprocess‘

Port 8001 is not reachable from outside

AzuraCast binds Icecast to `0.0.0.0:8001‘ on the host. If you have a host firewall, open the port to the outside world.

Here is an iptables example:
# iptables -A INPUT -p tcp --dport 8001 -j ACCEPT

But if you implemented the Apache reverse proxy as I outlined above, you would not have to expose this port at all. Instead you can rely on Apache httpd to relay user connections to the Icecast listen port on the host. The iptables firewall rule is then not needed of course.

Final thoughts

I found that AzuraCast does most of what my (t)rusty old OTTO did, and it is capable of considerably more that I am not even touching (but you might, if you are interested in running an actual live radio show with contributers).
The AutoDJ implements my primary need which is a maintenance-free jukebox: it handles the continuous queue filling without any intervention. The listener request system gives me an on-demand control over what plays next. My only gripe is that the AutoDJ pushes its own queue out to the player and any user request will be pushed out after that already pushed-out queue.  Which means that I need to keep the AutoDJ queue length limited to 1 or 2 songs so that I don’t have to wait too long for my own requested song to play.
The scheduled library scanning handles my ever-growing MP3 collection. And my music players just need to tun into a different Icecast URL.

If anyone is interested, I can describe in a future article how I deployed  YTuner locally to revive the network audio streaming capability for my Denon AVR-X2300W tuner after Denon killed its free online VTuner service by making it subscription-based. Because that Denon tuner is what’s playing my Icecast stream right now, while I am typing this.

I hope you enjoyed the article. Leave your thoughts in the comments section below.

Cheers, Eric

DAW question for Slackware 15.1: Pipewire or JACK Audio?

March 29, 2026 / / 4 Comments

I bought a new laptop to do some more serious work on, and while I was setting up the audio, installing JACK Audio Server and friends, I wondered what would be the proper path forward for a Slackware DAW (Digital Audio Workstation) when Slackware 15.1 is released with all the improvements over the 15.0 stable release.
Should I stick with JACK or look into Pipewire to get rid of the Jack server? Jack can be a bit finicky at times on this new laptop. The audio hardware uses Sound Open Firmware, which is new to me and often I need to restart JACK once or twice via QJackCtl before I actually get sound out of the laptop.

To make an informed decision, let’s first examine what PipeWire actually aims to improve. I confess that because of what I learnt during  my research, the article is a bit biased but hey! Feel free to contribute to the discussion at the bottom of the page!

State of affairs

Linux audio has historically been a layered affair. ALSA talks to the hardware, and one (or more) sound servers sit on top:

  • PulseAudio: handles desktop/consumer audio mixing, Bluetooth, networked audio. As we all know, its drawback is a high latency. It’s definitely not “DAW-friendly”.
  • JACK: the professional audio server. It delivers ultra-low latency and a flexible routing between apps. But it comes with a steep learning curve and is not trivial to manage. It is rather hostile to consumer-grade applications that rely on Pulseaudio, unless you bridge them.
  • PipeWire: built as the solution to all of the above problems, aiming to replace both and also (importantly) acting as a drop-in for each.

This is how the audio stack on Linux looks from the point of past/present and future:


You see where I am going…

 Pros of switching to PipeWire for a DAW

  1. One server to rule them all
    The benefit that I see is the elimination of complexity. We would get rid of having to run two parallel audio servers. In the legacy setup, PulseAudio mostly handles browser audio, Bluetooth, and desktop sounds while JACK is running the DAW. Getting them to cooperate requires that you install a Pulse-JACK bridge (via the pulseaudio-jack package) which is a temperamental setup. PipeWire replaces both of those audio servers with a single daemon that implements all three protocols simultaneously via pipewire-pulse, pipewire-jack, and pipewire-alsa compatibility modules.
  2. JACK applications just work, unmodified
    PipeWire aims to offer capture and playback for both audio (and video, let’s not forget!) with minimal latency and support for PulseAudio, JACK, ALSA and GStreamer-based applications. This means that programs like Ardour, Carla, Hydrogen, Guitarix, and every other piece of software I added to my Slackware DAW project will connect to PipeWire’s JACK compatibility layer without recompilation. The ABI is compatible; programs don’t know they’re talking to PipeWire.
  3. Latency has matured significantly
    Early PipeWire had a reputation for higher latency than native JACK. That criticism is much less valid today. Already long before the 1.x releases, the latency was reduced as low as using just JACK on top of ALSA.  PipeWire supports the same realtime thread priorities and can be tuned with “quantum” (buffer size) settings comparable to JACK’s “period/frames” parameters.
  4. Video routing and screen capture come along for free
    The daemon can be configured to be both an audio server (with PulseAudio and JACK features) and a video capture server. This matters for screen-casting, OBS, webcams, and Wayland portal-based screen sharing. They all go through the same flow that handles your audio.
  5. Flatpak and containerised applications work properly
    Yeah, I use Flatpak. Particularly to have a Signal messaging app on my desktop. Multimedia is an issue there. But PipeWire uses a Polkit-like security model, asking Flatpak or Wayland for permission to record screen or audio, rather than relying on audio/video group membership.
    This is a solution for a genuine pain point with JACK plus PulseAudio in any sandboxed context.
  6. WirePlumber provides intelligent session management
    The PipeWire session manager WirePlumber (which replaced the older pipewire-media-session) automatically handles device routing decisions. This means for instance, you simply plug in a USB audio interface and It Just Works. With JACK you would have had to restart the server or run manual scripts.

Caveats (Especially for a DAW)

  1. Extreme latency requirements still favour native JACK
    For professional studio scenarios demanding the absolute floor of latency (sub-8ms round trips, preferably below 5ms even, dense plugin chains) the picture is more nuanced. Under JACK, you can isolate cores, prioritize IRQs, and force absolute determinism. Under PipeWire, your latency will jump if anything interrupts real-time threads. PipeWire is getting better, but native JACK under a PREEMPT_RT kernel remains the gold standard for this specific use case.
    For most home studio and ‘prosumer’ DAW setups, you will not notice the difference.
  2. Configuration requires a different mental model
    Well what’s new. I am still not fully comfortable using JACK and QJackCtl’s patchbay metaphor. PipeWire on the other hand uses WirePlumber for policy management. Quantum (buffer size) and sample rate tuning is done differently. There’s yet another learning curve.
  3. Slackware’s ‘pipewire-enable.sh’ script has a precondition you must not ignore
    An important operational point is the check whether JACK is installed and the daemon is running. If that’s the case you should opt in consciously and disable JACK server manually, not have it silently taken over by PipeWire.

Is the JACK Server Still Needed?

The short answer: no, not as a running daemon. But of course there are layers below that answer: what about the runtime dependency on JACK because all those audio applications were compiled against JACK?
When pipewire-jack is installed (my add-on to the pipewire package in Slackware), it provides a drop-in JACK compatibility library. Programs that link against libjack.so will, after PipeWire is enabled, actually be talking to PipeWire under the hood. The jackd process itself does not need to run.
What does that look like:

  • libjack.so is the library that applications link against. It is still needed because it provides the ABI that JACK-aware programs call into. PipeWire provides its own version of this library when pipewire-jack is installed.
  • jackd / jackdbus is the server binary. This is no longer needed as a running process once PipeWire takes over as the audio server.
  • qjackctl is the control GUI for JACK. Fortunately this can be replaced by qpwgraph (from the same author who created qjackctl). Qpwgraph is the PipeWire-native patchbay application, obviously inspired directly by qjackctl.

And therefore the practical implication: if you have JACK installed on your Slackware DAW system alongside PipeWire, you need to ensure the JACK server does not start at login while PipeWire does start. The “pipewire-enable.sh” script in Slackware handles the PipeWire side; you simply should not start the daemon, jackd.

Connecting it all – the patchbay

What are the considerations when moving from qjackctl to qpwgraph?
As I said earlier, the author of qjackctl also wrote qpwgraph and the similarities are obious. Qpwgraph is a Qt-based graph and patchbay for PipeWire, and it saves your wire sets. It is the natural successor to qjackctl as part of a  DAW project that uses PipeWIre. The interface is visually very similar to qjackctl’s patchbay view, but it shows PipeWire’s full graph: the audio ports, MIDI ports, and video streams; all together. The connections that you create are saved by WirePlumber and restored on the next login.
If you still prefer qjackctl, that is not an issue because it can also connect to PipeWire via the JACK emulation layer.Its JACK-specific transport controls and the JACK server start/stop buttons become meaningless however.

What’s in the future for Slackware DAW

Given all of the above, this is what I think:

If you run an amateur home studio or you are a musician whose priority is “everything just works with minimal fuss“, switching from JACK to PipeWire looks like the future. Run ‘pipewire-enable.sh‘ once, install qpwgraph (it’s already in my repository) and use it as your new patchbay.
After you switch to PipeWire, the “Pro Audio” profile in pavucontrol (yes, it is a Pulseaudio tool) used in combination with a PipeWire audio server provides raw, direct access to all available input/output channels on your USB audio interface, bypassing standard stereo mixer restrictions. It is ideal for professional interfaces with multiple inputs/outputs, supporting low-latency and enabling advanced routing for your DAW.

On the other side of the spectrum you have your ultra-low-latency professional use. It’s the use-case for a dedicated professional recording studio, where you would be looking at sub-5ms latency requirements, a PREEMPT_RT kernel, hardware with specific JACK-tuned drivers. In this scenario, the traditional JACK-only configuration remains the preferred setup of your DAW.

The good news is that PipeWire does not break the JACK ecosystem. It absorbs it. If you are comfortable having a JACK-based signal flow (Carla, Ardour, Guitarix chains), you can migrate to PipeWire transparently and your setups will continue working. The most obvious difference being that there is no more need to manually start a JACK server or maintain a bridge to PulseAudio.

Your ideas

My biased story tried to convince you that a switch from JACK to Pipewire in Slackware DAW may be the right thing to do, but I also write this to convince myself 🙂 I am very much a person of “don’t try to fix what is not broken” but I see the benefits for most of us, Slackware users.

Still, there is a hard choice to be made. Should I recompile all my audio applications in the absense of JACK package to get rid of that dependency altogether? Or should I keep JACK, and keep all packages dependent on its libraries, and leave it up to you, the user, to run “pipewire-enable.sh” and replace qjackctl with qpwgraph? The former is cleaner but the latter gives more options.
Let me know your thoughts in the comments section below!

Eric

Sonic Pi 4.1.0 packaged for Slackware – and for live coding musicians

September 4, 2022 / / 5 Comments

Sam Aaron worked long and hard towards a new major release of his Sonic Pi software, and kept us informed about his coding journey on Twitter. Eventually a 4.0.0 version saw the light of day, 17 months after the  final 3.x  version (3.3.1) came out. Sam writes really informative release notes, I encourage you to check them out on his release page. Lots of enhancements and fixes to be enjoyed.

You don’t know what I am talking about?

You’ve probably missed my last year’s blog post then.
Sam Aaron is a musician and a programmer, holding a PhD in Computer Science. He develops a really cool program called Sonic Pi, meant to educate people in making music and learning how to code at the same time.
Sonic Pi uses the engine of Supercollider, which is another live coding platform. But Sonic Pi makes the art of live coding – performing on stage or just having a blast creating music on your computer – very low-threshold. Out of the box, when you start the program, its GUI will show complete and working coding examples, a tutorial, and an intuitive interface to start producing music straight away:

I have created packages for sonic-pi 4.1.0, the latest release, and I guess I am the first to create 32bit packages for a Linux platform, since I had to teach the “vcpkg” program that 32bit Linux is actually a thing. You could have guessed it… vcpkg is a cross-platform library manager created by Microsoft (!!!) which Sonic Pi uses to compile the libraries it needs.
I’ll see if I can create a patch for 32bit Linux support and send it to them.

Anyway, a month ago Sam Aaron gave a lecture at Lambda Days 2022 in Poland, about Sonic Pi, and here is a link to a recording of that lecture. You’ll learn more by watching that video, than by reading my blog posts about it.

The new packages (for Slackware 15.0 and -current) can be downloaded from all the usual places, for instance my slackware.com primary site, or the fast NL, UK or US mirrors.

I hope you are going to give Sonic Pi a try and that I’ll hear from you in the comments section below if you came up with a cool piece of audio.

And because Sonic Pi is contained in my Slackware Live DAW edition, I have also generated a new ISO for the Digital Audio Workstation. Get the “slackware64-live-daw-current.iso” ISO file, and copy it to a Ventoy USB stick or use the “iso2usb.sh” script to create a persistent USB stick.
This live environment should allow you to run Sonic Pi out of the box even if you have no idea how to configure the JACK audio server.

Have fun! Eric

December updates and a Christmas goodie for cable geeks

December 27, 2020 / / 34 Comments

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

October 7, 2020 / / 33 Comments

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

« Older posts

© 2026 Alien Pastures

Theme by Anders Noren — Up ↑