Thereās been a number of transitions. OSS to ALSA (c 2003), ESD/aRts to Pulseaudio (2007/2008) and, more recently, Pulseaudio/Jack to Pipewire which is, kind of, still ongoing. I suspect it was this latter one you encountered.
Do give a quick explanation of all of these, ALSA (Advanced Linux Sound Architecture) is baked into the Linux Kernel. Itās a low-level driver similar to ASIO (although it actually has far more capabilities) and replaced the original āOpen Sound Systemā (OSS).
ALSA is the low level subsystem that directly provides the drivers for specific hardware devices and presents a unified interface.
Note that Linux does not have the quite same concept of ādriversā that Windows has, and is more in line with Mac OSX. On Linux, the drivers are developed as modules that are compiled within ALSA. They are dynamically loaded, but you canāt really ship them independently of the OS.
Note that, in the old days, the only way to plug an audio interface into an old-style IBM PC was to open it up and plug a PCB ācardā in. Hence the terminology āsound cardā is often used:
These days, we have high-speed external ports like USB or Lightning, and almost all audio interfaces plug into one of these. The concept of the āsound cardā is largely obsolete, but the terminology still lingers on.
In the world of USB (which will be 99% of the audio interfaces used by people here) there are standards for how USB Audio works. When a USB audio interface is plugged into a PC, it communicates with the PC and describes itself: how many inputs, how many outputs, what resolution, how many MIDI ports, mixing controls, switches, etc.
In Linux (and Mac, and also in Windows, and Android and, I think, in iOS) there is a generic āclass compliantā USB driver which should be able to handle any USB audio device plugged into it without any further software being required. Unfortunately, a lot of manufacturers in the early days chose to deviate from that standard and, hence, drivers were required to deal with specific āquirksā. The Linux kernel is full of code to deal with these āquirksā, but not every audio interface is supported.
The great news is, increasingly, manufacturers have seen the wisdom of following the standards. Part of this is because they want their devices to work on mobile phones and tablets, where installing a driver isnāt viable.
But whilst ALSA is great for managing audio devices, and it can manage multiple audio devices and applications, itās not really very good at it. For modern desktop OSs, you need to be able to have multiple applications use multiple devices at the same time, with capabilities like setting volumes for different applications.
On Linux, this was, originally done by various subsystems, known as ādesktop sound serversā the main ones being āEnlightened Sound Daemonā (ESD) and āAnalog Real-Time Synthesizerā (aRts). The latter was part of the KDE Framework, and was extremely powerful, including a full modular synthesis engine.
These were, eventually, replaced by PulseAudio which was a very flexible desktop sound server. It didnāt have a modular synth (shame) but it did support Bluetooth, network audio, and streaming to various streaming audio systems (Airplay, Sonos, etc.). Pulseaudio sits over ALSA.
Around the same time (about 2005) the developer of Ardour, Paul Davis, realised that desktop audio servers were unsuitable for āpro audioā work (as the software mixing introduces unacceptable latency and degrades the audio streams), and developed Jack Audio Connection Kit (aka āJACKā). Jack also sits on ALSA, but provides a way for multiple applications to use a single interface in flexible ways. It includes a low-latency audio routing engine, a way to distribute tempo and clocks, transport controls, and virtual cable capability. JACK has been the default for āpro-audioā on Linux since 2005.
With JACK, you can connect a drum sequencer like Hydrogen to a MIDI sequencer, and to a DAW, and have the tempo and beat synchronised between them, pipe MIDI and audio between them, and have the start/record/stop controls on one control all the others. And JACK retained the low-latency of ALSA.
The virtual audio capability was extremely powerful. Hereās a screenshot I found from 2012 when I was doing live hangouts, using JACK for routing:
One problem was that JACK takes full control of whatever audio interface you point it at, so the normal desktop sound server has to be suspended. There were solutions to that, but it was messy.
Along came Pipewire with the aim of unifying things. It provides all of the capabilities of Pulseaudio (and is API compatible with it) and all of the capabilities of JACK (again, with full compatibility). The idea is, you donāt have to mess around with bridges and configuration or swapping between audio servers. It just works! It also works with containerised applications, and can support video streams and virtual cables as well as audio and MIDI.
The problem is, Pipewire has been undergoing fairly rapid development and really is only fairly recently considered stable. Despite this, some distros replaced Pulseaudio with Pipewire early on in itās development, and this has caused some problems. I suspect itās this you encountered.
If you have a recent modern distro, the chances are it will have a stable version of Pipewire, although it can be worth checking what the version is. I believe anything past v1.2.x is good (I am currently running v1.4.9 on my Kubuntu systems).
Cheers,
Keith
current focus is just getting back to playing again on a regular basis.
But Iām sure itās easier these days - when I tried, there was a big transition in the Linux world between an older, rather outdated audio system and a newer which still was not as reliable back then.
