ZenLinux Blog

I have several audio devices connected to my Linux desktop machine, including a USB audio interface (a MOTU M4), and a Jabra wireless headset that uses a USB dongle, and appears as its own audio device. I also like to use Bluetooth headphones on a daily basis.

After switching to Pipewire as my audio backend, I found that my default audio device wasn’t switching automatically to what I wanted – I’d always have to set it manually. I’d need to do this when my BT headphones would connect (select the a2dp headphone profile), and then again when I disconnected them (because I wanted to hear sound from my MOTU audio interface, but it would automatically fallback to the Jabra headset device). This is a two-part recipe to fix these issues.

Step 1: Make pipewire automatically select my Bluetooth headphones sink when they connected. This didn’t require any configuration changes. Instead, I have a script which runs on startup of my desktop environment which runs pactl load-module module-switch-on-connect. This is actually a pulseaudio command, but desktop apps still use the pulseaudio interface, which pipewire implements as part of the pipewire-pulse package.

Step 2: Make my default audio device my MOTU M4 audio interface, and stop selecting the Jabra headset device when I disconnect my BT headphones. This turned out to be caused by the fact that the Jabra audio device had a higher priority than my audio interface. Run the command wpctl status to show a list of your audio devices, and make a note of the device number. In this case, I was looking for the M4 device in my list of Audio Sinks. Then you can run wpctl inspect <device-number> to show the details of this audio device. What you’re looking for are the fields priority.driver and priority.session. Larger numbers correspond to a higher priority, but for sinks, they should be kept no larger than 1500 (otherwise a sink’s monitor could end up being selected as a default source – this is called out in the Wireplumber documentation). In my case, the Jabra sink had a priority of 1008, so I chose to set my audio interface to a priority of 1050.

Update May 2024: Wireplumber as of v0.5 no longer uses lua scripts for configuration. Check which version of wireplumber you’re using, and if you’re on 0.5, please refer to this guide to update the lua script below to the new format (and file location). I’ll update this blog post further when I have the time.

To change this configuration, you’d do so in Pipewire’s session manager. The preferred session manager for Pipewire is Wireplumber, which uses lua scripts to apply these kinds of custom configurations. So in my case, I created the file ~/.config/wireplumber/main.lua.d/60-raise-motu-m4-priority.lua with the following code:

rule = {
  matches = {
    {
      { "node.name", "equals", "alsa_output.usb-MOTU_M4_M4MC0570FU-00.Direct__hw_M4__sink" },
    },
  },
  apply_properties = {
    ["priority.driver"] = 1050,
    ["priority.session"] = 1050,
  },
}

table.insert(alsa_monitor.rules,rule)

Then, restart the wireplumber service with systemctl --user restart wireplumber and compare the new output from wpctl inspect. You should now see that the driver and session priorities are what you set them to. And when pipewire automatically switches to a new audio device, the highest priority device should be chosen.

I’ve found Pipewire and Wireplumber’s documentation to be confusing, and there are lots of dead-ends you can go down when researching how to do this. I hope this recipe-style blog post is easier to understand if this is the problem you’re trying to solve.

Many thanks to PleasantlyFlailing on the r/linuxaudio subreddit for suggesting some improvements to this blog post!

I’ve recently made the switch to using Pipewire on my Linux desktops. One thing I noticed in my list of audio devices was an entry for my HDMI monitor, which I never planned to use. I also do some music production on my Linux machines, and disabling this audio device would help my patchbay configurations look a bit cleaner.

Pipewire’s documentation is pretty basic, and when searching for this solution online, I went down several incorrect paths. We could really use more recipe-style examples on the web, so here’s mine. This is done using the Wireplumber session manager.

First, identify the audio device to disable using pactl list short. In the output from this, I could see an entry for the audio sink (alsa_output.pci-0000_27_00.1.hdmi-stereo-extra2.monitor) and for the audio device (alsa_card.pci-0000_27_00.1). It’s the alsa_card device that you want to disable, not the sink.

Update September 2024: Wireplumber as of v0.5 completely changed their configuration format from lua to json, and won’t automatically migrate your configuration. Before proceeding, check which version of Wireplumber you have installed.

For Wireplumber < 0.5, the configuration format is lua scripts. For this example, I created the file ~/.config/wireplumber/main.lua.d/51-disable-hdmi-devices.lua with the following code:

rule = {
  matches = {
    {
      { "device.name", "equals", "alsa_card.pci-0000_27_00.1" },
    },
  },
  apply_properties = {
    ["device.disabled"] = true,
  },
}

table.insert(alsa_monitor.rules,rule)

For Wireplumber 0.5 and later, the configuration format is json. For this example, I created the file ~/.config/wireplumber/wireplumber.conf.d/51-disable-hdmi-devices.conf with the following code:

monitor.alsa.rules = [
  {
    matches = [
      {
        device.name = "alsa_card.pci-0000_03_00.1"
      }
    ]
    actions = {
      update-props = {
        device.disabled = true
      }
    }
  }
]

Then, restart the wireplumber service with systemctl --user restart wireplumber and this audio device should now be gone – you won’t see it in your sound settings or in your patchbay diagrams.

On more than one occasion, I’ve found that the device names have changed after a major update – I’m not sure if this is due to a kernel change or a change in pipewire/wireplumber. But if things suddenly stop working and you’re seeing devices you thought you had disabled, go back to running pactl list short and see if your device name has changed.

For reference, I’m using pipewire and wireplumber on Manjaro Linux, which is a rolling release distro and tends to stay pretty close to the upstream software releases. I ultimately learned how to do this via the Arch Wiki page for Wireplumber, though at first I got confused about the need to specify an audio device instead of a sink. That caused me to think this was the wrong solution, and I spun my wheels for more than a week trying other things (e.g, turning the device profile off in pavucontrol) which didn’t work. Another handy reference for the wireplumber 0.5 config change update is this migration guide. Best of luck with your audio configuration journey!

In a kind of interesting mix between unconferences and programming contests like the Rails Rumble, Portland is holding a Startup Weekend event the first weekend in March. The idea is to bring together people of different backgrounds – including software developers, marketers, attorneys, and so on – and see what kind of product ideas they can start developing over a focused weekend of effort. With a bit of luck and a lot of elbow grease, some of these ideas and teams are likely to blossom into full-fledged technology startup businesses.

When I first read about this event I felt a kind of nervous energy as the realization crept in that yes, this was going to be one hell of an effort, and I would have very deep regrets if I didn’t give it a shot. So I registered for the event and look forward to some high-intensity growth experiences.

For the most part I expect the product ideas to be web application or web service-related. However given my background in embedded Linux systems, I’m planning to bring a couple of embedded boards with me and see if anyone is interested in developing an idea based on a physical product that could be sold. I’ve been becoming a big fan of the gumstix platform, but am also quite excited about the Sheeva Plug.

If anyone else in the Portland area is reading this and is even remotely considering attending, I urge you to go for it! Even if a viable business doesn’t come out of the weekend, there’s no doubt it’s going to be an incredible way of networking with other startuppy people and learning a lot about yourself.

I am extremely grateful for all of the people who showed up to hear my OpenEmbedded talk this evening at Roots. Michael Dexter noted that we had one of the best turnouts for a PLUG Advanced Topics meeting in a long time.

Here are the slides from the presentation. Unfortunately a lot of the good, interactive stuff happened during the live demo portion of the talk, but the slides do give a good overview of what the rest of the talk was about.

Enjoy!

Next week I’ll be giving a presentation on OpenEmbedded at the Portland Linux User Group’s Advanced Topics meeting:

Getting started in embedded Linux development can be intimidating. Every hardware device vendor seems to have its own embedded Linux distribution and way of developing for it. OpenEmbedded (OE) is a framework for creating highly customizable embedded Linux distributions. It provides a well-designed build system and cross-compilation environment to developers, and a robust package management system for setting up and maintaining your embedded Linux system.

Find out why OpenEmbedded is taking the embedded world by storm and improving the lives of embedded Linux developers.

Feel free to join us at Roots Organic Brewing, 1520 SE 7th Ave in Portland, at 7pm on Wednesday, Feb. 17. We meet in a room toward the back of the building. I’ve noticed the acoustics of the place are pretty poor, so I’ll be borrowing a sound system to help improve the presentation.