Advanced Linux Sound Architecture (ALSA) or Sound Servers to Mute and Unmute

1. Introduction

Although audio is rarely mandatory in a Linux system, having sound can be a nice distraction such as system sounds, entertainment in the form of music, or even convenience when it comes to online VoIP applications. Still, in all of these cases, we might want to temporarily prevent the system from producing audio notifications, similar to the silence function of a phone. Since Linux usage is very often a command-line endeavor, we only discuss command-line interface (CLI) options to do this.

In this tutorial, we explore how audio works in Linux with the example of muting and unmuting the system audio from the CLI. First, we go through the general audio setup of a Linux system. After that, we show how to mute and unmute at different levels of that context.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. It should work in most POSIX-compliant environments unless otherwise specified.

2. Audio Setup

With regard to sound, the Linux ecosystem usually relies on several main component types:

                 +-------------------------+
       SOFTWARE  |      Applications       |
                 +-----------+-------------+
                             |
                             |
                  +----------+------------+
                  | PipeWire |    JACK    |
SYSTEM SOFTWARE   +-----------------------+   SOUND SERVERS
                  |      PulseAudio       |
                  +----------+------------+
                             |
                  +----------+------------+
                  |    Advanced Linux     |
KERNEL, DRIVERS   |  Sound Architecture   |
                  |        (ALSA)         |
                  +----------+------------+
                             |
                             |
                 +-----------+-------------+
                 | Equalizer | Sound board |
       HARDWARE  +-----------+-------------+
                 |   Mixer   | Sound card  |
                 +-----------+-------------+
                 |          ...            |
                 +-------------------------+

On the bottom, we have physical HARDWARE audio devices of all types. Above them is the KERNEL, which also works with DRIVERS to support the hardware and communication with the operating system (OS). Next, we see SYSTEM SOFTWARE like sound servers, audio routers, and other such middleware. Finally, at the highest level, we have userland SOFTWARE like music players, voice and general sound recorders, and the like.

2.1. Kernel Support and Userspace Library

The Advanced Linux Sound Architecture (ALSA) framework is an open-source project providing the be-all and end-all way of dealing with audio devices under Linux. It sits between the hardware and the higher-level OS and application components.

In fact, ALSA is an integral part of the Linux kernel with a number of features:

• automatically configure sound cards
• include and set up device drivers
• hardware mixing of channels
• full-duplex
• application programming interface (API) for raw audio operations

Further, ALSA is the successor of the older and now long-deprecated Linux port of the Open Sound System (OSS).

There are a number of user-land tools included in the framework:

• alsactl: main control utility for [init]ialize, store, and restore card configurations, manage the main ALSA daemon, and monitor the framework
• amixer, alsamixer: pure command-line and terminal user interface (TUI) mixers to control audio values for ALSA-driver devices
• arecord, aplay: aliases for ALSA sound recorder and player

These rely on the ALSA library.

To get the complete toolset, we can install alsa-utils via apt:

$ apt install alsa-utils

Of course, we need to have kernel support for ALSA and compatibility with our sound device.

2.2. Audio Routing

Audio routing is the process of sending audio from one place to another:

• physical cable transmission
• physical jacks and inserts
• virtual device-to-application transmission
• virtual audio stream redirection

Despite the fact that ALSA provides this functionality, its API is more basic.

2.3. Sound Servers

Although comprehensive, ALSA is a very low-level package with fairly rudimentary functionality with regard to actual sound processing and routing. So, sound servers sit atop ALSA and provide higher-level and more comprehensive solutions when it comes to audio routing, mixing, and effects.

In particular, as we already saw in the diagram, sound servers work between ALSA and upper-level applications. There are many such servers, but several are more prevalent:

• PulseAudio, pulseaudio package, control via pactl: simpler and less feature-rich, better for beginners
• JACK, jackd and qjackctl packages, control via qjackctl: low-latency, professional
• PipeWire, pipewire package, control via PulseAudio: universal, experimental

To install, we can use apt with the relevant packages. JACK doesn’t require qjackctl, but we almost certainly need it for finer control over the package components.

In summary, the idea behind sound servers is to take control of the ALSA devices. While PulseAudio and JACK redirect all audio through themselves, PipeWire can be configured to use some of the features that ALSA provides.

2.4. Sound Server Emulation

While we can work without a sound server, some applications such as the Mozilla Firefox Web browser require it. Yet, even in these cases, we can avoid the full installation and setup by using emulation:

$ apt-get install apulse

In this case, we install the apulse package, which can be used to expose a mock upper-level PulseAudio-like API that directly links to ALSA. This way, applications that expect such an API can work with it without configuring a full-fledged sound server.

Due to the potentially complex sound pipeline, we might be able to interrupt the audio on many levels of its transmission.

3. Stop and Start Audio (Mute and Unmute)

To demonstrate how the Linux audio setup works, let’s explore how we can mute and unmute all sounds in different ways.

3.1. ALSA

First off, we look at muting at the lowest level with ALSA:

$ amixer set Master mute

In this case, we mute the Master channel with amixer. Channels can connect different sources and destinations. The Master channel usually affects all others. In rare cases, it’s just the default.

To enable sound after it was muted, we can use unmute:

$ amixer set Master unmute

Finally, we can reverse the current setting:

$ amixer set Master toggle

If required, it’s possible to specify a given channel to work with by selecting from the output of amixer scontrols. In the cases above, we can use set or sset.

Of course, we can also disable ALSA completely by killing the daemon:

$ alsactl kill quit

Naturally, ALSA might start up again after a reboot. Let’s enable ALSA manually:

$ alsactl init

Using alsactl, we can kill and re[init]ialize the whole audio system base.

3.2. Sound Server

If we intercept sound that goes through our sound server, we might miss some applications that produce sound directly through ALSA. Still, most sound server commands affect lower as well as upper levels.

For example, let’s mute PulseAudio:

$ pactl set-sink-mute @DEFAULT_SINK@ true

In this case, we use a so-called sink, namely, the DEFAULT_SINK.

To unmute PulseAudio, we use false:

$ pactl set-sink-mute @DEFAULT_SINK@ false

Again, we can toggle from one state to the other:

$ pactl set-sink-mute @DEFAULT_SINK@ toggle

Of course, we can select any sink, i.e., destination, by name or number. Also, true is 1, while false is 0. The pactl command with its info flag can tell us the current Default Sink.

Since sound servers can just be devices within ALSA, amixer can control them as well:

$ amixer -D pulse set Master toggle

Here, we toggle the pulse [-D]evice, assuming that’s how PulseAudio is exposed to ALSA.

Naturally, we can use several methods to disable the PulseAudio sound server:

$ systemctl stop pulseaudio.socket
$ systemctl stop pulseaudio.service
$ pulseaudio --kill
$ killall pulseaudio

To respawn, i.e., unmute, we can again use systemctl or pulseaudio.

While we only covered PulseAudio, the same principles often apply to other sound servers.

3.3. Application

User applications can pick their audio handler depending on integration, development support, and user preference. Some use ALSA directly, while others prefer to go through any or a specific sound server.

Because of this, we should target the application’s preferred handler or use built-in controls of the application itself.

For example, the widely used VLC media player offers a command line switch for muting:

$ vlc --v4l2-audio-mute [...]

Other ways include interactive graphical user interface (GUI) or TUI buttons, settings, and similar.

4. Summary

In this article, we talked about the audio setup in Linux and how to cut off sound completely.

In conclusion, whether at the lowest level with ALSA, or higher up with sound servers or applications, we have many ways to mute and unmute all or source-specific sounds.