I’ve been spending some laptop time in one of our louder studios of late. Since switching to Linux for philosophical reasons, the challenge emerged to integrate this sometimes under-supported operating system into the workflow expected of an audio professional. This article will be updated on the go as I plough through the pitfalls, while sharing tips and workarounds I’ve discovered along the way to make the music flow. It will evolve as I learn.

Although many Linux distributions exist, some specialised for creatives, my explorations have been using stock Linux Mint 22.3. Often using base packages provided by the Software Manager for maintenance and stability, rather than the latest and greatest. With that in mind, the journey can begin.

Caution: The command line lurks ahead…

Not only Pulses and Pipes, but ALSA

Although the “Plug and Play”-ability of Linux hardware has improved dramatically over the years, use of audio hardware demands a deeper understanding of the different layers that come together to control sound output.

At the base level, there is ALSA, the Advanced Linux Sound Architecture. This is a kernel-level device layer that connects to the hardware directly. Offering the basics for sound capture and playback, but nothing much more than that. Software-based Virtual Devices can also be configured at this level, which I’ll touch on later.

Historically, PulseAudio was implemented as a user-level layer on top of ALSA, allowing the mixing of multiple audio streams. Individual volume levels could be set for each application, and sound routing could also be switched on the fly, such as when headphones were plugged in. Applications would use the PulseAudio API to connect to this sound server instead of hitting the hardware directly, with the complexities abstracted away.

Another audio server, JACK (JACK Audio Connection Kit. Gotta love a recursive acronym!) was used at a professional level, also abstracting ALSA. Designed for low-latency studio applications, it would allow for accurate synchronisation and explicit audio routing. However, this server was incompatible with PulseAudio, as only one or the other could connect to ALSA at a time. Systems running both required a lot of workarounds and bridging.

PipeWire is a modern evolution and replacement of both PulseAudio and JACK, revised to handle the needs of both audio and video processing as well as MIDI transfer. Able to emulate both the API and toolset of its predecessors, this layer is low-latency by design.

Modern audio implementations mostly use PipeWire, although some applications may hit ALSA directly. A few caveats remain when switching between the two.

The DAW is the Law

Although I’ve limped along with GarageBand on other devices, the job demands a Digital Audio Workstation (DAW) with a bit more control.

Many professional options are available, with Ableton Live, Avid Pro Tools, and Apple Logic Pro coming highly regarded for Windows and MacOS. Linux options are somewhat more limited, but Reaper offers a native version. All these options come with a price-tag, often shifting to a subscription licence instead of owning outright.

Ever the zealot, I went with Ardour – which has the advantage of being free-as-in-speech Open Source software. Donations to the developers are welcome for a ready-to-run supported binary version, but the source code is available for anyone who wishes to build their own.

As for me, I grabbed the pre-built version 8.4 package from the Linux Mint Software Manager. It’s a few versions behind, but sufficient to the task.

(Using a DAW effectively is beyond the scope of this article, mostly because I’m still learning the intricacies itself!)

One thing I did notice when connecting straight to ALSA is my Dock audio only permits a 48 kHz sample rate, which made importing CD-rate 44.1 kHz stems (individual audio tracks) a little troublesome, with clicks and pops aplenty. As expected, ALSA also takes sole control of the device, removing it from the available list in Sound Settings.

Switching to the PulseAudio system (running through Pipewire as explained earlier) enabled sample rates from 8 kHz to 192 kHz through the ‘Default Playback’ device, which outputted onto the Laptop’s speakers instead of through the dock. Switching the default through the Sound Settings panel soon got things coming out of the expected speakers at the right rate, without stealing control.

Pull the Plug-in

Ardour comes with a bevy of workable LV2 ACE plugins to handle the basics of Compression, Gating, et al. But most of these rely a little too much on sliders and numbers than the familiar knobs and blinkies of a real mixing desk. Downloading the pre-built binary improves the look, but nonetheless the effects chain is easy to navigate, allowing drag and drop visualisation of where everything clicks together.

It is also compatible with industry-standard plugin formats such as Virtual Studio Technology (VST), offering a more familiar interface, but here is where Linux users hit a snag. The underlying format of these plugins has been designed for Windows, and thus incompatible.

Undismayed, I found yabridge able to convert the plugins so that they work just fine, with full custom interface intact. Utilising the Windows compatibility layer offered by Wine, yabridge relinks the VSTs to the equivalent native libraries, allowing them to be added to Ardour. The Software Manager has an older version of wine, but again it does the job:

Once wine has installed, grab a prebuilt yabridge release, (current version 5.1.1), as a tarball, then extract it to ~/.local/share. (‘~’ being the home directory.)

Copy your .vst files into ~/.vst3, then just run the following from ~/.local/share/yabridge:

After a little churning, a bunch of new directories will be created under ~/.vst3, storing .so files for each of the plugins. The original files can be deleted if need be, (they’ll just show up as Errors), but ultimately the working versions are easy to find in Ardour’s Plugin Manager, where they can be enabled and added to the chain:

Donning my Electric AXE

Now we’re mixing it up, the next challenge is to get audio in and out.

I’ve been using the IK Multimedia AXE I/O One as external soundcard of choice for a few years now. An ideal device that can receive 1/4″ jack and balanced XLR input, sending the post-DAW signal to headphones, amp, and line-out. Connecting via USB-C, it works with just about everything. Although IK does not formally support Linux, a little tweaking can coax it into life.

When first plugging it in, the first surprise is that nothing happens. Checking sound settings reveals a new analogue input source, but nothing else. Time to troubleshoot.

First thing I tried was listing the USB devices to make sure it had been picked up properly.

So at least it exists. Next I checked the ALSA hardware layer.

So it’s there as a playback device. Next comes the USB Audio kernel module, just to make sure that’s working:

At this point I was able to see the card as an ALSA device in Ardour, but it still wasn’t available elsewhere. So, I needed to go higher up to Pipewire:

So, looking at this, it seems the card IS visible to Pipewire, with an audio sink (output), but the pro-audio active profile doesn’t play nice with desktop.

Investigating the Pipewire sinks further:

Now I know it’s visible, I can set it as the default sink and send a test signal to the PulseAudio device exposed by PipeWire:

(I could also have sent it to the plughw:2,0 PipeWire device which wraps the raw hardware.)

It was at this point I realised my headphone volume was maxed, and 4000 Hz really is an unpleasant frequency.

The card was working at the desktop level, and after a swift blast of ‘Procreation (Of the Wicked)’ to soothe my delicate ears, I went to see if I could use it this way in Ardour. After some starting and stopping of the DAW’s sound server, it worked!

However, the card was still not available in Sound Settings, probably due to the aforementioned pro-audio profile. So I just needed to map it into something Pipewire could use elsewhere:

(Note to the overwhelmed reader: THIS IS THE IMPORTANT BIT!!!!!)

And with that, the AXE popped up in the Sound Settings with a somewhat mangled name – but at least it works and I could test it from there.

Going back to Ardour, the default PulseAudio device could be changed from this control panel, and the audio switched seamlessly. Success!

Finally, all I had to do was add the remap to a script to run whenever I wanted to plug the card in. Automating this can be finessed later, but it’ll do for now.

Welcome to Helvum

Helvum is a great little tool to help visualise audio flow. Acting as a virtual patchbay, signals can be dragged from application to audio sink, with the remapped AXE sink appearing as both a Playback input and output.

The AXE itself appears with three playback_AUX channels. AUX0 and AUX1 are Left and Right headphone/line out respectively, and AUX2 the amp output.

If patches are lost for whatever reason, they can be remapped here. Counter-intuitively, patches are deleted by dragging the same link from node to node again, but this soon becomes second nature.

A Divine Comedy of Compatibility

Broadcasting beyond the confines of my laptop into a wider world of connectivity, the next step is to get it to speak the Dante protocol. Developed by Audinate, Dante is the media industry standard for synchronising and transmitting low-latency multi-track audio (and video) digital data across Ethernet, with bandwidth far in excess of the multicores of old. And of course, it isn’t supported on Linux.

Fortunately, a clean-room reverse-engineering of the protocol exists. Appropriately named Inferno, it is a software-only implementation thatis still very much experimental and not recommended for real-world productions. However, it should be sufficient for my goal of sending a ‘Band in a Box’ from my laptop to a mixing desk.

Like the author’s depiction of the afterlife, getting this working requires purgatorial levels of fault finding and configuration hacking. As of writing, I’m not quite there yet, but here’s what I have so far…

First, I needed to build everything. Following the instructions at the main code repository, I soon realised I needed to obtain a second package – statime – to allow for network clock synchronisation.

This got me all the code I needed. As both projects are written in the Rust language, I also had to install the latest version of the language via rustup, despite my reluctance to pipe random code from the Internet into the shell.

With the code in place, I built statime with cargo build, and edited the inferno-ptpv1.toml file to include my correct ethernet interface, enp4s0. Then I kicked everything off:

Lots of trace messages scrolled up, so I thought I’d better stop it for now to build the main virtual ALSA device. First I needed some extra development libraries:

And then I ran another cargo build from the alsa_pcm_inferno directory. This created a library which needed to be linked into the correct directory.

With the virtual device library in place, the next step was to get it to appear to ALSA. Taking hints from both the readme documentation and a useful set of forum posts, I created an .asoundrc file in my home directory, roughly containing the following:

This would create a raw ALSA device, as well as a plug for that device to allow it to be called from Pipewire. I knocked the available receive and transmit channels down to two apiece, just to make it easier to test by sending two-channel audio from the command line.

Happily, the virtual devices became visible to ALSA:

But not to aplay -l, which only lists physical hardware.

At this point I was ready for testing, so I chained my laptop’s Ethernet to a pre-existing ad-hoc Dante network consisting of a Midas M32, DigiCo Quantum 225, and a MacBook running Dante Controller and Reaper. Making sure to set my Ethernet’s IP to a similar range to the rest. The intent being to run some test sounds over the network to see if they work.

The main issue in all of this was the clock. My Ethernet port has no hardware timing, so I also experimented with setting up a software clock with ptp4l:

Eventually, I was able to get a positive response from playing audio into the virtual device, showing that the clock was eventually found and stabilised. However, the device still wasn’t appearing in Ardour, despite my trying other ways to access the plug.

At this point the studio session was over so I had to continue at home, where the clock didn’t work at all. After subsequent digging, I conclude a physical Dante hardware device must be available to provide a reliable clock signal, even when the software clock is acting as master, so my investigations have paused for now.

Hopefully I’ll be able to get these last few tweaks working when I’ve got access to a Dante-compatible desk again.

The journey continues

Although I’m a lot closer than I was when I started, there are still a few things that could be better to ensure Linux has its place in a professional audio environment. More research and experimentation is essential, and this article will be expanded accordingly as I go.

*Inferno*, Canto XXXIII*, 1865. Heads frozen in the lake of Cocytus. (1865) by Luigi Ademollo, from Divine Comedy.

Source: Cornell University Library

https://pdimagearchive.org/images/5a0cf6cc-2042-43b4-a3a9-2a9d1ec05612

#hell #dante #inferno #art #publicdomain

Plan9

My summer break in 2014 had a theme of sorts, which was “back to basics”. I wanted to forget everything I could about work and fiddle with more interesting stuff – less abstraction(...)

#att #inferno #legacy #lucent #os #plan9

https://taoofmac.com/space/os/plan9?utm_content=atom&utm_source=mastodon&utm_medium=social