Linux Audio

Hardware

The audio process starts with physical hardware like sound cards which contain digital-to-analog (DAC) and analog-to-digital (ADC) converters. These cards also often have built-in components such as headphone amplifiers and pre-amplifiers for microphones.

Musical Instrument Digital Interface (MIDI)

MIDI is different from audio: it is a standard protocol for communication between electronic musical instruments and computers. MIDI signals are not sound themselves, but rather instructions that tell a synthesizer which notes to play, how long to hold them, and at what velocity. Unlike audio, which is a continuous analog signal that needs to be converted into a digital representation, MIDI data is inherently digital and carries event-based information that represents musical notes and other performance data.

Tip

Some audio interfaces include a built-in MIDI interface, which allows both audio and MIDI to be handled by the same physical device.

Drivers

The Linux kernel requires device drivers to interact with the sound card. Initially, OSS (Open Sound System) was used, but it had limitations and became proprietary. ALSA (Advanced Linux Sound Architecture) replaced OSS and is the standard driver today. It handles the low-level communication with sound cards allowing software to read and write audio data. ALSA however, has limitations in that only one application can control the hardware at a time, which is not practical for most users.

Channels, Buses and Ports

A channel represents a single path for audio or MIDI data. Audio can be monophonic (one channel) or stereophonic (two channels), or use even more channels (multichannel audio).

• A physical sound card has input and output channels, allowing it to send and receive audio
• In software, a track in a Digital Audio Workstation (DAW) can also have multiple channels
• MIDI also utilizes channels; each channel can be assigned a different instrument or program, allowing a single synthesizer to play multiple parts [2].

A bus is a pathway that combines and routes audio signals: multiple signals can be inputted into the bus simultaneously and cannot be separated after entering the bus, so that all devices (which can read from it simultaneously) receive the same mixed signal [4].

A bus can have multiple channels, allowing for the routing of multi-channel audio and buses are used to send audio to effect processors. There There are different types of buses, like the master bus, which combines all audio tracks, and sub-master buses, which combine audio before it reaches the master bus [4].

A port is a software-defined input or output point for audio or MIDI signals, managed by a Sound server like JACK, PulseAudio or PipeWire. Each application that interacts with a sound server has its own input and output ports.

Sound Servers

To solve the limitations of ALSA, sound servers like PulseAudio, JACK, and now PipeWire were developed. These act as intermediaries between applications and the sound card, allowing for multiplexing of audio streams and additional features like mixing, resampling, and routing.

PulseAudio

PulseAudio is a sound server that sits on top of the ALSA driver. It enables multiple applications to play audio simultaneously by mixing different audio streams into one output, resampling if necessary to match the output of the sound card. Benefits:

• Multiplexing: Allows multiple applications to play or record audio concurrently from the same sound card.
• Resampling: Converts different audio sample rates (e.g., 44.1 kHz from CDs, 48 kHz from videos) to a uniform rate for playback, which is often 48 kHz.
• Device Management: Facilitates the selection of different audio output devices (e.g. headphones, HDMI). Individual Volume Control: Enables per-application volume adjustments. Limitations:
• Latency: Has higher latencies (40-80ms) which are not ideal for pro audio applications.
• Routing Flexibility: Limited routing capabilities, making complex audio routing configurations difficult.

JACK

JACK is a sound server designed for professional audio applications, offering high flexibility and low latency. Key Features:

• Virtual Patch Panel: Allows flexible routing of audio between any input and output of any application, described as “like a physical patch panel”.
• Low Latency: Provides lower latencies suitable for music production and real-time processing.
• MIDI Support: Includes support for MIDI, which is essential for many pro audio tools.
• Hardware Interaction: Interacts more directly with hardware, handling higher sampling rates more effectively. Limitations:
• Complexity: Can be harder to use and configure compared to PulseAudio.
• Compatibility: Often incompatible with PulseAudio, requiring workarounds such as routing through JACK after PulseAudio, causing latency problems

PipeWire

PipeWire aims to be the next-generation audio server, designed to replace both PulseAudio and JACK. Key Features & Goals:

• Drop-in Replacement: Provides a drop-in replacement for both PulseAudio and JACK, supporting their APIs.
• Unified System: Allows for simultaneous use of both PulseAudio and JACK applications.
• Flexible Routing: Incorporates the patch panel approach of JACK allowing complex routing of audio streams.
• Video Multiplexing: Aims to provide multiplexing of webcams using GStreamer, allowing multiple programs to use the camera simultaneously. Current Challenges:
• Bluetooth Issues: Bluetooth support is buggy and sometimes devices do not connect properly.
• Resampling Artifacts: Issues with resampling between PulseAudio and JACK applications can cause artifacting.
• Stability: While making progress it is still noted to be experimental and buggy in some situations.

Tip

PipeWire aims to combine the ease of use of PulseAudio with the power and flexibility of JACK. It is seen as the future of the Linux audio ecosystem.

Note

PulseAudio has a history of stability issues, leading to a negative reputation, though it has long been the main audio server on most Linux systems. PipeWire also had a rocky start, with users experiencing instability and issues like microphones being recognized as outputs.

1. How can I identify my audio devices and their associated kernel modules in Linux? You can use several command-line tools to identify your audio devices and the kernel modules that are handling them. To find PCI audio devices, use lspci and look for entries with “Multimedia controller.” The “Kernel driver in use” line from this output will show the loaded module. For USB devices, lsusb —verbose —tree | grep —after-context=1 ‘Class=Audio’ is helpful. To see all loaded sound modules, use lsmod | grep ‘^snd’. Finally, cat /proc/asound/cards lists your sound cards with their corresponding index numbers.

2. What is the significance of /proc/asound and how can I use it for debugging? The /proc/asound directory provides a virtual file system interface to the ALSA (Advanced Linux Sound Architecture) drivers. Each file within this directory exposes internal information about your sound system, such as card details, device parameters, and module configurations. By examining these files, you can diagnose problems and gain insights into ALSA’s behavior. Specifically, /proc/asound/cards lists available sound cards, and the general information about the procfs tree can be found in “Proc Files of ALSA Drivers.” The format of /proc/asound/cards is detailed in the “General Overview” section of the ALSA library API Control Interface.

3. How can I configure the order and indexing of my audio devices? The order in which ALSA assigns indexes to sound cards can sometimes be unpredictable, particularly with USB devices. To control this, you can use the slots and index options when loading sound modules. The slots option, for example slots=,snd_hda_intel,snd_hda_intel,snd_usb_audio, allows you to specify which modules should be loaded and in what order. The index option lets you assign specific card numbers, like options snd_hda_intel index=2,1. For USB audio devices, the snd-usb-audio module has vid and pid options to ensure consistent device assignment regardless of order.

4. How does the ALSA configuration file (/etc/asound.conf) allow for advanced routing and mixing? The /etc/asound.conf file allows for flexible configuration of audio routing and mixing. It uses a syntax to define various pcm devices which can then be used to manipulate audio. For instance, you can set up a dmix device to enable multiple applications to play audio through the same sound card. The provided example configures both analog and digital outputs through dmixa and dmixd respectively. Furthermore it demonstrates how to implement an equalizer using plug:dmixd, and a volume control for digital output using softvol. It also shows how to combine analog and digital output into a single quad output device, and how to setup a virtual stereo to quad routing device called stereo2quad.

5. What are some important aspects of sound level and dynamic range in audio production? In audio production, it’s crucial to understand concepts like the K-system, headroom, equal-loudness contours, sound level meters, listener fatigue, dynamic range compression, and alignment level. The K-system provides specific metering practices for different scenarios and musical styles. Headroom refers to the available space above the average signal level before clipping occurs, which helps prevent distortion. Equal-loudness contours show how human ears perceive different frequencies at different volumes. Sound level meters measure the loudness of sound. Listener fatigue happens from prolonged exposure to audio, which can be detrimental to mixing decisions. Dynamic range compression reduces the difference between the loudest and quietest parts of an audio signal. Alignment level is a standard reference level used to calibrate recording and playback equipment.