Linux Audio Software: General stuff

Majik · December 17, 2025, 12:40pm

I thought it might be useful to start a more general thread to discuss Linux based audio stuff that doesn’t really fall into the other topics: things like OS configuration, audio drivers, routing, and utilities.

I’m going to start with a discussion of Linux audio setup because, well, it’s a good place to start!

At the end of the day, the Linux audio architecture isn’t that dissimilar from Windows or Mac, but there are some practical differences which are important.

Firstly, unlike Windows, but more like Mac (or iOS/Android), when you purchase a new audio interface, there aren’t any “drivers” to download and install for Linux. This is because, if the device is supported on Linux, the audio drivers are built-in.

How does this work?

For most of us, we will be using audio interfaces which connect via USB. The USB standard includes a way for a USB device to report its capabilities to the host computer when it is plugged in. This is done using a “device descriptor”. Within the specification for USB Audio, the device descriptor describes all of the inputs, outputs, controls, formats and sample rates for the device.

By using the device descriptor, Linux can “suss out” what a particular audio interface is, and automatically adapt to it. This is all handled by part of Linux called “ALSA” (Advanced Linux Audio Architecture".

In the sections below, I have described some “nerdy” detail. This is the sort of stuff that gives Linux the reputation for being complex or requiring a high level of expertise. In reality, you don’t generally need to know this stuff.

One of the differences on Linux, compared to Windows and Mac, is that this sort of detail is exposed and easily accessible whilst on other platforms it’s largely hidden.

I’ve hidden this behind detail tags because it really is only for the inquisitive. You really don’t need to know or care about it.

Example of device descriptor for a Boss Katana GO

The following is an example of a device descriptor for a Boss Katana Go. The output is from the Linux command lsusb -v and shows the header with the device manufacturer, product name and other details.

Bus 001 Device 016: ID 0582:0304 Roland Corp. KATANA:GO
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0582 Roland Corp.
  idProduct          0x0304 KATANA:GO
  bcdDevice            1.00
  iManufacturer           1 BOSS
  iProduct                2 KATANA:GO
  iSerial                 0 
  bNumConfigurations      1

This is followed a Configuration descriptor which contains key information about the device configuration, such as it’s power requirements and the number of Interfaces.

  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x00f9
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA

This is followed by Interface sections which describe the various capabilities. Firstly the device topology is described by the “AudioControl” Interfaces. This is the “map” of how audio flows in the device:

terminal IDs 1 & 3 are the Playback paths (PC → device)
terminal IDs 4 & 7 are the Capture paths (device → PC)
The device supports 16 bit audio at 48kHz. Note that this device has a fixed resolution. Other devices may offer multiple options.

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0035
        bInCollection           3
        baInterfaceNr(0)        1
        baInterfaceNr(1)        2
        baInterfaceNr(2)        3
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             1
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          0
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             3
        wTerminalType      0x0602 Digital Audio Interface
        bAssocTerminal          0
        bSourceID               1
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             4
        wTerminalType      0x0602 Digital Audio Interface
        bAssocTerminal          0
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             7
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          0
        bSourceID               4
        iTerminal               0

The “AudioStreaming” interface describe the device inputs and outputs including the streaming format, sample rates, data transfer mechanism, and other technical capabilities. Each of these includes an “endpoint” descriptor which represents an audio channel.

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              5 KATANA:GO AUDIO
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              5 KATANA:GO AUDIO
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           1
        bDelay                  0 frames
        wFormatTag         0x0001 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x0d  EP 13 OUT
        bmAttributes           13
          Transfer Type            Isochronous
          Synch Type               Synchronous
          Usage Type               Data
        wMaxPacketSize     0x00cc  1x 204 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress           0
        AudioStreaming Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay         0x0000
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              6 KATANA:GO AUDIO
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              6 KATANA:GO AUDIO
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           7
        bDelay                  0 frames
        wFormatTag         0x0001 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        48000
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x8e  EP 14 IN
        bmAttributes           13
          Transfer Type            Isochronous
          Synch Type               Synchronous
          Usage Type               Data
        wMaxPacketSize     0x00cc  1x 204 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress           0
        AudioStreaming Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x00
          bLockDelayUnits         0 Undefined
          wLockDelay         0x0000

This device has MIDI capability ( used by the control app to configure the device, switch patches and so on). This is described in the “MIDIStreaming” Interface blocks.

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      3 MIDI Streaming
      bInterfaceProtocol      0 
      iInterface              4 Generic Audio MIDI 1.0
      MIDIStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0041
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               1 Embedded
        bJackID                16
        iJack                   8 KATANA:GO MIDI IN
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               2 External
        bJackID                32
        iJack                  10 KATANA:GO MIDI OUT
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               1 Embedded
        bJackID                48
        bNrInputPins            1
        baSourceID( 0)         32
        BaSourcePin( 0)         0
        iJack                  10 KATANA:GO MIDI OUT
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               2 External
        bJackID                64
        bNrInputPins            1
        baSourceID( 0)         16
        BaSourcePin( 0)         0
        iJack                   8 KATANA:GO MIDI IN
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)      16
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (Invalid)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)      48

What Linux see when an audio interface is plugged in

When an audio interface is plugged into Linux, it is detected and the device descriptor read, and used to create an audio device automatically. This can be seen in the logs:

[68225.749930] usb 1-8.1.1.2: new full-speed USB device number 16 using xhci_hcd
[68225.836791] usb 1-8.1.1.2: New USB device found, idVendor=0582, idProduct=0304, bcdDevice= 1.00
[68225.836802] usb 1-8.1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[68225.836806] usb 1-8.1.1.2: Product: KATANA:GO
[68225.836810] usb 1-8.1.1.2: Manufacturer: BOSS
[68225.845499] usb 1-8.1.1.2: Quirk or no altset; falling back to MIDI 1.0

And, as it’s a USB device, it can be seen by running the lsub command:

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 003: ID 0451:8442 Texas Instruments, Inc. 
Bus 001 Device 004: ID 1397:00d4 BEHRINGER International GmbH XR18
Bus 001 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 008: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 009: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller
Bus 001 Device 010: ID 0451:82ff Texas Instruments, Inc. 
Bus 001 Device 011: ID 046d:085b Logitech, Inc. Logitech Webcam C925e
Bus 001 Device 012: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID
Bus 001 Device 013: ID 076b:3021 OmniKey AG CardMan 3021 / 3121
Bus 001 Device 014: ID 056a:00d1 Wacom Co., Ltd CTH-460 [Bamboo Pen & Touch]
Bus 001 Device 015: ID 31e3:1232 Wooting Wooting Two HE (ARM)
Bus 001 Device 016: ID 0582:0304 Roland Corp. KATANA:GO

Note that the device has two numbers against it. This is the unique vendor id (0582=Roland Corp.) and the device ID (0304=Katana GO).

The device descriptor can be found using lsb -v -d 0582:0304

At the command line, the aplay command can be used to list playback devices:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: XR18 [XR18], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: PCH [HDA Intel PCH], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: PCH [HDA Intel PCH], device 1: ALC1220 Digital [ALC1220 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: NVidia [HDA NVidia], device 3: HDMI 0 [DELL U3818DW]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 4: KATANAGO [KATANA:GO], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Similarly, capture devices can be listed with arecord:

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: C925e [Logitech Webcam C925e], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: XR18 [XR18], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: PCH [HDA Intel PCH], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: PCH [HDA Intel PCH], device 2: ALC1220 Alt Analog [ALC1220 Alt Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 4: KATANAGO [KATANA:GO], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

And MIDI devices with amidi:

$ amidi -l
Dir Device    Name
IO  hw:1,0,0  XR18 MIDI 1
IO  hw:4,0,0  KATANA:GO MIDI OUT

When a device is plugged it, it is normally automatically detected and will show up in the audio settings:

And in audio controls:

On modern desktop Linux using Pipewire (I’ll explain this in a later post), it will also show up in the Pipewire graph. Here I’m using qpwgraph to view it:

So, for most people, audio interfaces on Linux are “plug’n’play”.

There are exceptions, especially with older devices:

In the past, a lot of vendors were lazy or secretive with their devices, and wouldn’t fully describe them in the USB device descriptor. They would then ship a downloadable “driver” (which, in many cases, was a text file containing a structured description of the stuff which should have been in the USB Device Descriptor).

Sometimes they would implement things in non-standard ways or add capabilities which were outside the standards (aka “quirks”) and which could not be discovered using standard USB audio semantics.

A lot of these devices won’t work on Linux unless the proprietary stuff is reverse-engineered and implemented into ALSA. The good news is this has been done for a lot of devices. I, myself, have helped the ALSA developers implement the quirks for a range of Roland devices, including the Katana amps.

But, increasingly, vendors are moving towards more standard USB audio devices because they’ve realised that proprietary shenanigans prevents these devices from being used on phones and tablets, which is now a big market for them.

Cheers,

Keith

Majik · December 17, 2025, 12:51pm

I should mention control apps.

A lot of vendors will expose additional capabilities in a control application which is, typically, only available for Windows or Mac.

In a lot of cases, someone in the Linux community will reverse engineer this and create a Linux equivalent. A good example of this is the alsa-scarlett-gui app for the Focusrite series:
Demonstration

Another one is FX Floorboard for Boss products, including the Katana:

It’s important to note that not all devices have an equivalent Linux controller, and the manufacturer’s site will usually only provide information for Mac and Windows, so you’ll need to research if this is important to you.

A good example of a device that works under Linux but which doesn’t (currently) have a control app is the Lewitt Connect 6.

Cheers,

Keith

DavidP · December 17, 2025, 1:38pm

Thanks Keith, appreciate you sharing all this for our benefit

sequences · December 17, 2025, 3:26pm

I look forward to this. I have used Linux since about 1998, but haven’t started to deal with audio outside of the defaults until I started playing guitar and wanted to record (about 2022). I have been dissatisfied with needing to manually hook up the patch cables in something like qpwgraph every time I log in new. If you can cover how to get these things persistent in your PipeWire post, that would be wonderful!

Also, Arch linux (and others, I expect) is still defaulting to PulseAudio. I know Debian has moved to PipeWire for the audio manager. I think those differences and how they relate to ALSA deserve some attention for folks just coming in to Linux new.

Thanks for these ! I think a Table of Contents style posting may be handy to post these individual links into.

Majik · December 17, 2025, 3:59pm

Possibly, and possibly not. There’s some dependencies here.

Yes, I was hope to try to explain some of this. Arch has some particular challenges when it comes to audio and Pipewire and I know a lot of people have got into a mess by trying to install/upgrade Pipewire on Arch and some other systems, often by blindly following AI generated instructions .

On Arch, I would suggest it’s best to stick with PulseAudio and Jack. Or just use ALSA, if you don’t need the routing capabilities.

Cheers,

Keith

sequences · December 17, 2025, 4:06pm

I resemble that remark… It works, but so many programs want to talk to pulseaudio that I still need the pipewire plugin that looks like pulse. When I want to plug in my Helix or any kind of interface, I need to go thru the manual hookups again. Maybe I just haven’t found the right reading yet.

The reason I use Arch on my workstation is because there are items in AUR I cannot find in other distributions. I use Debian elsewhere because it is low maintenance and basically works without much setup.

Thanks again for these!

Majik · December 17, 2025, 4:08pm

On most of the other distros I have used that have Pipewire by default, they have also configured the Pulseaudio and Jack plugins by default so that it all “just works”.

Cheers,

Keith

Majik · December 17, 2025, 5:24pm

OK, here goes.

This post is really going into the weeds of how Linux audio works for those who are interested. If you are using a modern, audio-focused Linux distro like UbuntuStudio or AVLinux, you really shouldn’t have to worry about most of this.

The situation described here is complex and I’m really summarising a couple of decades of history and development of the Linux platform (as well as missing out a whole bunch of historic detail).

I’ve also attempted a few diagrams to help describe what I’m discussing.

The Linux audio architecture is, as I have said, not unlike that on Windows or Mac. They are complex, layered architectures designed to provide different capabilities depending on the needs of the application and the user.

With Linux, the baseline audio capability is ALSA. This is baked into the mainstream Linux kernel and provides interfacing with hardware and an API for applications to use. In most practical modern cases, the hardware is a USB connected device, and ALSA interoperates with the kernel USB subsystems to communicate with the audio hardware.

This is, roughly, equivalent to what is known as “audio drivers” on Windows, but ALSA is also equivalent to ASIO on Windows except, on Linux, it’s a built-in capability.

As such, applications which require audio can use ALSA directly, just like they use ASIO directly on Windows:

One important point is that the application connecting to ALSA gets exclusive control of that audio hardware. This means no other application can use it to play or record audio.

(Note that this is the same as ASIO on Windows - for good reasons I will discuss later).

Now, whilst this is OK for some setups, it’s generally useless for modern desktop operating systems where you have multiple applications running at the same time and all of them may want to use the audio device.

So, to cope with this modern desktop operating systems include a software layer between the applications and the kernel level which allows multiple applications to play or record audio. This software layer takes exclusive control of the audio device and does control and mixing of the desktop application audio to and from the audio device.

On Linux, this was, until fairly recently, done with a subsystem called “PulseAudio” (and some early subsystems like ESD and aRTs):

Now Pulseaudio is great BUT: all that software mixing and messing around does two things:

It modifies the original audio stream
It introduces a lot of latency

Now, for most applications, these are not issues. But for “pro-audio” production use, you really don’t want high latency and some other applications messing with your audio without your knowledge. In fact, most “pro-audio” demand the digital audio to be “bit-perfect”, and the only way to do this is for your audio application to have exclusive control of the audio hardware.

(Note the same is true on Windows, which is why ASIO exists).

So, some early audio applications would only talk directly to ALSA, which meant all other desktop audio would stop working.

Now, about 2 decades ago, some bright spark came up with the idea for an alternative layer which would be low-latency (by avoiding mixing) but which would allow multiple audio applications to talk directly to each other. This was useful because, during audio production, you may have multiple applications involved. If you can get them to talk together than you probably don’t need them to all access the audio hardware.

For example, you may want the connection of a software keyboard (vmpk) sending MIDI to an argeggiator (qmidiarp) and the arpeggiated MIDI output connecting to a software synth (qsynth). You want audio output qsynth connected to the input of a stereo channel in Ardour so you can record it. At the same time, you may want Hydrogen drum machine connected to a separate stereo track in Ardour for synchronised recording. The Master bus output of Ardour can then connected to the output of the audio interface.

If this can all be done with almost zero latency, and the only application that needs to directly talk to the audio hardware is the DAW, which also controls any mixing, then this is a Good Thing™.

So, this chap invented Jack Audio Connection Kit, or Jack for short. Jack talks to ALSA and takes exclusive control of the audio hardware, but also provides inter-application audio connectivity and routing as well as global transport and tempo sync.

Here’s what it looks like (using the GUI tool qpwgraph tool for the connections):

(MIDI connections are in red, audio connection in green):

I will be talking about Jack (and now Pipewire) routing capabilities in another post. But the important thing is that Linux has had virtual audio and MIDI routing capability as a standard for audio production for around 20 years.

Soon afterwards, audio production applications started using Jack by default, and everything was wonderful! Except…

Because Jack takes exclusive control of the audio hardware, that means anything that doesn’t talk to Jack (for instance desktop applications which talk to PulseAudio) won’t have audio.

What happens in practice is that desktop audio gets “turned off” whilst the audio production stuff is using the audio hardware:

Again, this is what happens in Windows with ASIO!

Now, Jack was shipped with nearly every Linux distro since the mid 2000s, but it was an optional capability. It was rarely installed or configured. If you wanted to do “pro-audio” work, you needed to install it (very easy) and configure it (less easy). This included disabling the desktop audio before you launched Jack.

A handful of audio focused distros either had Jack enabled by default, or had tools and pre-defined configs to make it easy to switch.

Eventually,the PulseAudio developers came up with a module that enabled PulseAudio to be “bridged” to Jack:

But most distros still just shipped Pulseaudio enabled, and left Jack as an optional install/config capability for those that wanted to do audio production.

Then, a few years ago, Pipewire appeared. Pipewire is an attempt to finally unify desktop app and “pro-audio” capabilities. It takes over from both Pulseaudio and Jack and provides many of the main capabilities of both. It has modules emulating the PulseAudio and Jack interfaces so that applications can use it.

Incidentally, Pipewire also provides virtual cable capability for video.

If you are using a modern, audio-focused distro then a recent version of Pipewire is typically installed by default and everything should “just work”.

Cheers,

Keith

sequences · December 17, 2025, 5:40pm

My apologies! I intended to nudge you to include this when you posted a future topic
I’d be good if you pulled the above and put it in a future topic instead. I see some things there that even after over 2 decades using linux that were not known to me.

Majik · December 17, 2025, 6:15pm

Well, I wanted to set the scene for future discussions where some of this stuff may be relevent, especially if we are talking about retrofitting/configuring a non-Pipewire distro like Arch.

Cheers,

Keith

TheMadman_tobyjenner · December 18, 2025, 7:54am

Though not a Linux user I found this write up fascinating.
A well documented description sir!

Majik · December 24, 2025, 11:38am

So, regarding this, are you talking about needing to start pipewire modules manually (e.g. pipewire-pulse or pipewire-jack) or are they in and working, and you are more concerned about getting audio applications connecting to the correct interfaces on your audio device?

Which audio applications are you using, and what audio hardware?

Can you give a screen shot of qpwgraph before you make the hookups?

Cheers,

Keith

sequences · December 24, 2025, 8:39pm

I can use pipewire-pulse, so that seems to be generally ok. My missing knowledge is that I need to frequently re-connect sources to sinc and possibly a volume control. I cannot make these reconnect when the source goes away and comes back. Spotify is a good example on chromium, when I start playback, I need to connect up the ‘wires’, then if I hit pause, the source disappears and I’ll need to reconnect wires back to the sinc once I hit play again. I am hoping there is a way to make this persist. I think there is a way, but haven’t found a clean and clear guide. May be something for my time off this week.

Nothing too special, chromium, mumble (almost always ok), Audacity (sometimes needs help, but can break other connections), Helix, PowerCab. I’ have fiddled with some other tools related to guitar, but not very often.

Away right now for Christmas, but I can see if I can get a proper image across remote. (not really proper - will try in a couple days when i get back home).

I think the biggest irritation is recording. I have a USB mic hooked up for mumble, but when I either use Chromium to record a song into Audacity, or I want to record from the Helix, then recording breaks on mumble until I restart it. I will sometimes lose any ability to get Audacity to select a source until I restart my login, so I know my login is at least resetting things.

Thanks for asking! Hope you have familiarity with the problem.

Michael

Majik · December 26, 2025, 2:54pm

It depends where you are trying to connect them. If it’s to an audio interface output then, generally speaking, this should “just work”: normally you have a default audio device that you can select and any new connections will try to use this.

By the way, I’m using Chrome as an example here as it operates similarly: connections in Pipewire appear and disappear dynamically based on audio output.

On my PC, for example, I have two available devices, and I have selected the “XR18 Mixer Stereo” one and this shows up both in the volume “widget” on my toolbar, and in the system settings:

You can also specifically control which device an application uses by selecting that application (when playing and, therefore, visible) and selecting which device it should use:

This only works with audio devices though. If you want to connect it to another application, then this won’t work.

There’s a couple of things you can do in that case.

If you only need to wire in an intermediate application for volume control between Spotify and the audio interface, look at EasyEffects. You can configure this to automatically intercept the output of specified applications and can apply a whole bunch of processing to that, which can include gain control, limiting, etc. and you can save that as presets. As long as you auto-run EasyEffects when you boot the desktop, it should automatically set up connections for you based on your configuration.

If you want to wire more applications than just a volume control then you probably need a different approach.

If you are already using qpwgraph, you can look at using the Patchbay capability. This lets you set up connections and save the state as a named patch. If this is loaded and activated, then it should automatically make the connections.

For example, I set up a stereo channel in Ardour and connected Chrome to it whilst it was playing back:

I then saved a new patchbay, made sure it was activated and, now, when I start Chrome it automatically connects to Ardour (if it’s running and if there’s a stereo track named “Chrome”).

I hope this helps.

Cheers,

Keith

Majik · December 26, 2025, 3:04pm

By the way, if anyone else is reading this and thinking: “this looks far too complex for me”, note that this is advanced audio and routing management which simply isn’t something that is available on Windows or even Mac OS out of the box (and, possibly not even with 3rd-party tools).

Yes, it is complex, but only if you want to use it. If you don’t then, generally, stuff largely works just as it does on Windows or Mac.

But if you do have uses for it, then it’s massively powerful (if a little frustrating, at time getting the configuration right).

As an example: I have an 18 channel audio interface which I normally have channels 17 and 18 for stereo playback from my PC. On both Windows and Linux, it either tries to use it as a multi-channel surround interface (which it is not) or defaults to using channels 1 & 2 which doesn’t work for me.

On Windows, I never found a solution. On Linux, I used a config file to create a “pseudo-device” which presents as a standalone stereo audio device, which happens to be connected to channels 17/18 on my XR18.

I can then just use this as a normal 2 channel audio interface.

Cheers,

Keith