![Cover image for Debian 12 … is amazing! How to: Create your custom codehouse #6 [Giving Voice to Debian: Wireless Audio Devices configuration]](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Flmszwq9vv606aovlqx1l.png)
In the previous article, I demonstrated all the steps required to set up a custom UI from scratch, including the display server, window manager, status bar and additional useful apps. Additionally, I shared my choices for fundamental apps, such as a terminal emulator and a browser.
Now, it’s time to complete the setup. What I configured previously was primarily focused on output devices—like the monitor, which handles what you see—and input devices like the keyboard and mouse, which allow interaction with applications. However, input and output audio devices remain untouched (in my case, a Marshall wireless Bluetooth headset with both a microphone for input and speakers for output).
My input/output audio device is only one—a Marshall IV headset (which I use mostly in wireless Bluetooth mode, but it also has a wired option). I don’t have separate speakers or a microphone. So, the first thing I need to ensure is that my Bluetooth dongle is working properly. I have written a detailed article dedicated to troubleshooting Wi-Fi and Bluetooth devices, so if your Bluetooth device gives you any troubles, please refer to that article.
My Bluetooth dongle works perfectly on Debian—truly plug and play. There’s no need for configuration, installation of drivers/firmware, or any tweaks; it just works. This Bluetooth dongle is from the brand Edimax, purchased on Amazon for around $10 (Edimax BT-8500). It supports the Bluetooth 5.0 protocol.
Therefore, my Debian system is ready to be configured to use my headset seamlessly for audio playback and, if needed, microphone input.
Here’s the road map for this article:
➀ Sound on your PC: where it starts (hardware-side)?
➁ Sound on your PC: where it starts (software-side)?
➂ ALSA, PipeWire or Pulseaudio: what is better*? (*trick question)
➃ Bluetooth devices management tool
➄ PipeWire vs Pulseaudio
➅ PipeWire: Installation
➆ About XDG Desktop Portal
➇ Pipewire audio profiles: Understanding the difference between device profile headset-head-unit and a2dp
➀ Sound on your PC: where it starts?
Let’s start by understanding what is the crucial component of your PC which determines whether you can enjoy any audio or not. It’s not just about having speakers/microphone, a headset, or anything else that can actually play/register sound. Your PC needs a hardware piece capable of processing audio at a very low level. That job is done by sound cards.
A sound card is a computer expansion card that can input and output sound under program control. (Source)
If you have a laptop or a PC—or if you built a PC manually and you are worried that you might have forgotten some piece—there’s nothing to worry about in 99% of cases; your machine has a sound card. Modern machines typically have on-board sound cards integrated into the motherboard.
Depending on your motherboard’s specifications, the quality of the integrated sound card will vary, and that directly affects the quality of the sound your PC can produce or record. Some people who work with professional audio may find the capacities of integrated sound cards unsatisfactory, so they might opt for an additional sound card that can be attached via PCIe or USB (not all motherboards have PCIe slots for sound cards, though). However, for everyday use, an integrated sound card is usually very sufficient.
$ lspci -d ::0403 #::0403 here means Audio device subclass
00:1f.3 Audio device: Intel Corporation Raptor Lake High Definition Audio Controller (rev 11)
01:00.1 Audio device: NVIDIA Corporation GA106 High Definition Audio Controller (rev a1)
The first audio device is my motherboard’s integrated sound card. But what about NVIDIA Corporation High Definition Audio Controller? Why is it there? Can I use it?
Nvidia High Definition Audio allows NVIDIA GPU to transmit audio to any display (monitor or TV) with built-in speakers, provided it has an audio-capable connector (most commonly HDMI or DisplayPort). By using Nvidia HD Audio, you can enjoy various uncompressed and lossless audio formats, which can significantly enhance your overall listening experience—especially if you’re using modern displays with integrated speakers.
However, my monitor is pretty simple and it does not have any audio device. So, I will be using on-board soundcard.
➁ Sound on your PC: where it starts (software-side)?
As with any hardware device, a sound card needs firmware and drivers to function. On Debian, you usually don’t have to worry about these, except in cases where something is messed up with the kernel modules—this can often happen if Debian is running on a virtual machine. Yes, like most drivers, sound card drivers are part of Linux kernel, so it’s the Linux kernel that provides them to your Debian.
$ lspci -k -d ::0403
00:1f.3 Audio device: Intel Corporation Raptor Lake High Definition Audio Controller (rev 11)
DeviceName: Intel HD Audio
Subsystem: ASUSTeK Computer Inc. Raptor Lake High Definition Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel, snd_soc_avs, snd_sof_pci_intel_tgl
01:00.1 Audio device: NVIDIA Corporation GA106 High Definition Audio Controller (rev a1)
Subsystem: ASUSTeK Computer Inc. GA106 High Definition Audio Controller
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
Everything is alright with sound card's driver in my case - snd_hda_intel driver is present and in use.
➂ ALSA, PipeWire or Pulseaudio: what is better*? (trick question)
I have a sound card, I have drivers and firmware, and I have an audio output device—my headset connected via cable (let’s leave aside the Bluetooth management part for now).
So, I go to YouTube to listen to my favourite music band, Public Memory...
Well, I can’t hear anything (I can’t provide a screenshot as proof, though XD). So, what am I missing?
If you’ve ever Googled/troubleshooted about audio on Linux, most probably you’ve encountered the three names ALSA, PulseAudio, and PipeWire, regardless of your distro. Maybe, these names can be confusing. Are they alternatives to each other, do you need all of them, or which one is better? That’s why I gave this section its title. I want to answer these questions by exploring why I can’t listen to Public Memory - which software I am missing?
ALSA (Advanced Linux Sound Architecture)
_ Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.
Put simply, ALSA can be divided into two components: The kernel API that provides access to your sound card for higher-level sound servers and applications, and a userspace library that provides more general functions (like effects, mixing, routing, etc.)
There is no way to "replace" ALSA, with regards to the kernel API. Previously, there was also OSS (Open Sound System), but that's been deprecated for nearly 20 years. The same is not true of ALSA's userspace library, which can be replaced. (Debian Wiki: ALSA)_
Here we are! The first answer is: ALSA is a must-have. No ALSA = no audio. Moreover, you already have it on Debian, because it is the part of the Linux kernel, the same as sound card drivers. So, since I have the Linux kernel, I should already have ALSA installed.
Indeed, I have it:
# I check for presense of package that contains the ALSA userspace library and its standard plugins, as well as the required configuration files:
$ dpkg -l | grep libasound2
ii libasound2:amd64 1.2.8-1+b1 amd64 shared library for ALSA applications
ii libasound2-data 1.2.8-1 all Configuration files and profiles for ALSA drivers
Why I cannot listen to Public Memory, then?? T-T.
Well, if you haven’t been reading this series of articles from the first part, you might not know that when I installed my Debian, I used a super minimal installation: Debian Stable with only the standard system utilities. This setup is usually perfect for server environments, and the last thing you’d typically do on a server is play music. So, I do have ALSA, I have the drivers, and everything is ready for me, but it needs to be initialised. By default, it’s not initialised because Debian (if you choose this option during installation) doesn’t run/initialise anything you didn’t explicitly request (and I love it).
The initialization is quite simple: sudo alsactl init. However, I cannot use it because this command is part of the alsa-utils package, which is not installed by default on my setup and is not included in the standard system utilities. Therefore, I need to install it first.
$ sudo apt install alsa-utils
$ sudo alsactl init
Found hardware: "HDA-Intel" "Realtek ALC897" "HDA:10ec0897,104387fb,00100402" "0x1043" "0x87fb"
Hardware is initialized using a generic method
Found hardware: "HDA-Intel" "Nvidia GPU 9f HDMI/DP" "HDA:10de009f,1043881d,00100100" "0x1043" "0x881d"
Hardware is initialized using a generic method
Aaaannd magic! Public Memory divine music is in my ears!
Is ALSA restrictive in some way? Does it work only for one audio stream at a time?
For development purposes, I have multiple browsers installed, so I opened another Public Memory song in a different browser and played it simultaneously. It works—I hear the overlaying audio of both songs.
I think it’s time to set up Bluetooth management tools and try listening to songs using my wireless headset.
Note: Regarding the question posed in the section title, I haven’t fully explored it yet. For now, it’s clear that ALSA is the key to audio input/output working on Debian, and it’s functioning well for little tests I performed. I’ll leave advanced tests—like using the microphone, testing apps for calls, etc.—for later, as my priority now is setting up Bluetooth to use my headset wirelessly.
➃ Bluetooth devices management tool
I have a Bluetooth adapter (dongle Edimax BT-8500) and a Bluetooth device (Marshall IV headset).
Basically, I just need to install the bluetooth metapackage.
Package: bluetooth (5.66-1+deb12u2)
This package provides all of the different plugins supported by the Bluez bluetooth stack
$ sudo apt install bluetooth
I won't be using any GUI for now; I'll use command-line tool bluetoothctl instead. First, I'll check if the bluetooth service is running.
$ systemctl status bluetooth
# if it is not running
$ sudo systemctl start bluetooth
Then, I run bluetoothctl and enter its CLI
$ bluetoothctl
[bluetooth]# power on
# i set the agent to handle pairing and set it to default mode:
[bluetooth]# agent on
[bluetooth]# default-agent
# start scanning devices
[bluetooth]# scan on
[NEW] Device XX:XX:XX:XX:XX:XX MAJOR IV
[bluetooth]# scan off
#numbers you see is unique MAC address of your audio device
# once I have the MAC address of my Marshall headset, I can initiate pairing:
# I PUT INTO PAIRING MODE MY MARSHALL HEADSET
[bluetooth]# pair XX:XX:XX:XX:XX:XX
Attempting to pair with 1C:6E:4C:84:CF:A7
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
[CHG] Device XX:XX:XX:XX:XX:XX Bonded: yes
...
[CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: yes
[CHG] Device XX:XX:XX:XX:XX:XX Paired: yes
Pairing successful
[CHG] Device XX:XX:XX:XX:XX:XX ServicesResolved: no
[CHG] Device XX:XX:XX:XX:XX:XX Connected: no
[bluetooth]# scan off
##Hmm, pairing is successful, but connection is no...
[bluetooth]# connect XX:XX:XX:XX:XX:XX
Attempting to connect to XX:XX:XX:XX:XX:XX
Failed to connect: org.bluez.Error.Failed br-connection-profile-unavailable
The error isn’t very self-explanatory. Something seems off. Bluez's corresponding error description still not entirely clear:
Failed to find connectable services or the target service.
However, nothing to worry, this isn’t really about troubleshooting or debugging. I just wanted to gently point you back to the unanswered question in the previous section - is having only ALSA enough?
First off, there are two guides for Debian on Bluetooth usage: one for non-audio Bluetooth devices, and another specifically for Bluetooth audio devices. The second one, the right one for my case, explicitly states:
Pre-configuration
In short: To connect to a given device, you need Bluetooth hardware on your PC (either built-in, or in the form of a USB dongle), the Bluez daemon, and a compatible audio server (either PulseAudio or PipeWire). Alternatively Bluetooth ALSA available since Debian 12 bookworm allows to avoid running of a high-level sound server. (Debian Wiki: Bluetooth Audio)
So, there are two options here:
You stick with ALSA only, using an additional package Bluetooth ALSA. In this case, you don’t need PulseAudio or PipeWire for Bluetooth audio devices to work.
Both PulseAudio and PipeWire, as mentioned above, are audio servers.
However, it may still be unclear why I can't simply use ALSA if it worked for wired music playback, and what's missing from my system. The answer is that, without additional software, the Bluetooth codec used by my Marshall headset isn't supported.
A codec determines how Bluetooth transmits from the source device to your headphones. It encodes and decodes digital audio data into a specific format. In an ideal world, a high-fidelity signal would be possible at the minimum specified bit rate, resulting in the least amount of space and bandwidth required for storage and transmission. Lower bitrates actually mean better compression but often mean worse sound quality, a high bitrate usually means better sound quality and worse compression. (Source)
There are more advanced codecs and less advanced ones. However, the use of codecs is somewhat bilateral. I mean, the choice I mentioned above—that you can go for just an additional package like Bluetooth ALSA or choose one of the sound servers—can be partially guided by the support of audio codecs out of the box. In this case, the winner is PipeWire. However, if your audio input/output doesn't support advanced codecs, there's no way to utilize them.
Interestingly, despite using Bluetooth 5.0, the my Marshall Major IV supports only the default SBC audio codec. This codec is adequate and the connection is stable, however it’s not ideal (source).
So, actually for my setup just additional package for bluettohb audio devices support for ALSA is viable version:
The
bluez-alsa-utilspackage supports the LDAC and SBC codecs. AAC support is not compiled into the official package, because the required library is only available in the non-free repository.
This will also automatically configure a "bluez-alsa" systemd service, and install the proper ALSA configuration files to glue everything together. No further steps should be necessary. If you run into issues after installation though, a reboot might help. (Source)
However, I would prefer to use a sound server on my setup.
➄ PipeWire vs Pulseaudio
Before comparing these two audio servers, it would be helpful to first understand what they do and why they’re needed except for the Bluetooth connection of audio devices.
In the previous article of this series, I installed and configured a display server as the first step in building my custom UI. The reason for this is that all graphical applications "live" on the display server, which handles all inputs and outputs. Moreover, there is an inter-process communication, the desktop bus, used by applications to communicate with each other, creating a kind of "graphical ecosystem".
A similar parallel can be drawn for sound servers. While ALSA is sufficient for many use cases, you might need a sound server for more advanced and dynamic audio usage. This includes not just playing music but also audio and video streaming, sharing screens with audio during calls, and leveraging advanced audio technologies and codecs. For most of these scenarios, a sound server becomes essential.
The difference between PulseAudio and PipeWire is somewhat analogous to the difference between the X11 display protocol and Wayland. The latter is a much newer technology, designed and developed to replace PulseAudio while addressing all of its shortcomings.
There’s nothing inherently wrong with PulseAudio—it’s neither abandoned nor outdated. However, PipeWire is more modern and, in some cases, offers out-of-the-box support for advanced audio devices without the need for tweaks or extra configuration. This isn’t relevant in my case since, as I mentioned, my Marshall Major IV headset only supports the very basic SBC Bluetooth codec. Nonetheless, I’ve decided to go with PipeWire.
PipeWire is a server and API for handling multimedia on Linux. Its most common use is for Wayland and Flatpak applications to implement screensharing, remote desktop, and other forms of audio and video routing between different pieces of software. Per the official FAQ, "you can think of it as a multimedia routing layer on top of the drivers that applications and libraries can use."
As opposed to PulseAudio's focus on consumer audio and JACK's focus on professional audio, PipeWire aims to work for all users at all levels. Among other techniques, PipeWire achieves this with its ability to dynamically switch between different buffer sizes, for adapting to the different latency requirements of different audio applications.
In Debian 12, PipeWire 0.3.65 is available, and is considerably more reliable, and is a comfortable drop-in replacement for many use-cases. PipeWire is the default sound server with GNOME Desktop. (Debian Wiki: PipeWire)
➅ PipeWire: Installation
In the previous article, while configuring the BSPWM window manager and display server, it was necessary to set up D-Bus for the X session. This is because, when initiating the graphical user interface with startx from the console, an X session managed by X11 is started, and it exists with BSPWM which executes all configurations specified in its setup.
Similarly, PipeWire requires a session manager to function effectively.
Two session managers are now available. The one pulled in by default (wireplumber) is the one recommended by pipewire's developers. The other one (pipewire-media-session) is primitive, and is best when using PipeWire just for its basic functionality like screensharing. When using PipeWire as your system's sound server, the maintainer recommends installing the more advanced WirePlumber instead. This command will install WirePlumber while removing the old session manager:_
So, I just need to install WirePlumber, and as a dependency, it will bring PipeWire to my system. There is this recommendation from Debian developers:
It is recommended to install the metapackage
pipewire-audiowhich depends onwireplumber(the recommended session manager),pipewire-pulse(to replace PulseAudio),pipewire-alsa(ALSA) andlibspa-0.2-bluetooth(for Bluetooth support). Moreover, installing this metapackage will removepulseaudioto prevent any conflicts between both sound server. (Source)
*NB! The Debian 12 Bookworm stable repository has quite outdated versions of the PipeWire sound server (v. 0.3.65) and its dependencies. Since PipeWire is young and evolving quickly, it may be important to have a more up-to-date version installed. So, the option to install it from Bookworm backports may be viable (v. 1.2.5), and later on, I will show you how. *
However, even if you decide to go for it, make sure to read the text below and check the logs, because otherwise, you might not understand the XDG Desktop Portal. A version of WirePlumber and PipeWire from Bookworm backports doesn't seem to complain about it, but trust me, you'll most likely need the XDG Desktop Portal."
$ sudo apt install pipewire-audio
$ systemctl --user start wireplumber
Now, I’ll check if everything is okay with wireplumber service:
$ systemctl --user status wireplumber
● wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-12-30 13:04:27 CET; 13s ago
....
Dec 30 13:04:27 wonderland systemd[1017]: Started wireplumber.service - Multimedia Service Session Manager.
Dec 30 13:04:27 wonderland wireplumber[6190]: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Dec 30 13:04:27 wonderland wireplumber[6190]: found session bus but no portal
Dec 30 13:04:27 wonderland wireplumber[6190]: Failed to set scheduler settings: Operation not permitted
Dec 30 13:04:27 wonderland wireplumber[6190]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Dec 30 13:04:27 wonderland wireplumber[6190]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Dec 30 13:04:28 wonderland wireplumber[6190]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.
Wireplumber is running, but there are a couple of things that aren't okay. Let's go through them one by one with the errors.
wireplumber: Failed to set scheduler settings: Operation not permitted
This is definitely something about permissions. It might be related to the fact that PipeWire version available on Debian Bookworm is low, so the permission issue is most likely due to the absence of a specific user group (pipewire) created with the necessary permissions when PipeWire is installed. The default group is used, but PipeWire needs more. Personally, I would leave it as is and only debug if something really doesn't work.
PipeWire's libcamera SPA missing or broken. libcamera not supported.
This is just about a PipeWire plugin, and depending on whether you need it or not, you can install it. I don't need it, so I’ll leave PipeWire to complain about the missing plugin. Here is the package for this plugin.
Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5
Well, here I am completely okay with it since I don't have devices that use legacy codecs. A2DP is exactly what I need:
Advanced Audio Distribution Profile (A2DP)
A standard for how Bluetooth devices that can stream high-quality audio to remote devices. This is most commonly used for linking wireless headphones and speakers to your PC. (Source)
What’s left is quite interesting, and it’s something you should pay attention to:
Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
found session bus but no portal
pipewire service reports the same issue in slightly different manner:
$ systemctl --user status pipewire
● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-12-30 13:04:27 CET; 12min ago
TriggeredBy: ● pipewire.socket
....
Dec 30 13:04:27 wonderland systemd[1017]: Started pipewire.service - PipeWire Multimedia Service.
Dec 30 13:04:27 wonderland pipewire[6189]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Dec 30 13:04:27 wonderland pipewire[6189]: mod.rt: found session bus but no portal
alisa@wonderland:~$
So, DBus User Message Bus is running correctly (I dedicated a very detailed attention to configuring it in the previous article). But something related to the desktop is missing...
What even is this?
➆ About XDG Desktop Portal
XDG Desktop Portal
A portal frontend service for Flatpak and other desktop containment frameworks.
xdg-desktop-portal works by exposing a series of D-Bus interfaces known as portals under a well-known name (org.freedesktop.portal.Desktop) and object path (/org/freedesktop/portal/desktop). (Source)
Mostly, it’s needed for containerized software like Flatpaks, as the quote above says. However, it’s not only for this, and even if you don’t use Flatpak, you could still run into problems. A very trivial case could be with a browser like Mozilla or any other when you try to upload something, and the file chooser dialog is needed. It won’t work without the portal.
Portals were designed for use with applications sandboxed through Flatpak, but any application can use portals to provide uniform access to features independent of desktops and toolkits. This is commonly used, for example, to allow screen sharing on Wayland via PipeWire, or to use file open and save dialogs on Firefox that use the same toolkit as your current desktop environment. (Arch Wiki: XDG Desktop Portal)
XDG Desktop Portal can be installed with sudo apt install xdg-desktop-portal on Debian. HOWEVER, THE COMMON MISTAKE IS TO INSTALL ONLY THIS PACKAGE. XDG Desktop Portal needs at least one backend (can have also more). There are different backends available on Debian Bookworm:
- xdg-desktop-portal-gnome
- xdg-desktop-portal-gtk
- xdg-desktop-portal-kde
- xdg-desktop-portal-wlr
I will proceed with installation of xdg-desktop-portal first.
Package: xdg-desktop-portal
desktop integration portal for Flatpak and Snap
xdg-desktop-portal provides a portal frontend service for Flatpak, Snap, and possibly other desktop containment/sandboxing frameworks. This service is made available to the sandboxed application, and provides mediated D-Bus interfaces for file access, URI opening, printing and similar desktop integration features. (Source)
$ sudo apt install xdg-desktop-portal
$ systemctl --user start xdg-desktop-portal
$ systemctl --user status xdg-desktop-portal
● xdg-desktop-portal.service - Portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
Active: active (running) since Mon 2024-12-30 13:29:28 CET; 1s ago
....
Dec 30 13:29:28 wonderland systemd[1017]: Starting xdg-desktop-portal.service - Portal service...
Dec 30 13:29:28 wonderland xdg-desktop-por[7132]: No skeleton to export
Dec 30 13:29:28 wonderland systemd[1017]: Started xdg-desktop-portal.service - Portal service.
$ systemctl --user restart wireplumber
$ systemctl --user status wireplumber
● wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
Active: active (running) since Mon 2024-12-30 13:29:46 CET; 7s ago
...
Dec 30 13:29:46 wonderland systemd[1017]: Started wireplumber.service - Multimedia Service Session Manager.
Dec 30 13:29:46 wonderland wireplumber[7157]: Failed to set scheduler settings: Operation not permitted
Dec 30 13:29:46 wonderland wireplumber[7157]: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
Dec 30 13:29:46 wonderland wireplumber[7157]: PipeWire's libcamera SPA missing or broken. libcamera not supported.
Dec 30 13:29:47 wonderland wireplumber[7157]: Trying to use legacy bluez5 API for LE Audio - only A2DP will be supported. Please upgrade bluez5.
WirePlumber just wanted the XDG Desktop Portal available, without the specific backend. So, after installing the XDG Desktop Portal and starting it as a service, the errors in the WirePlumber and PipeWire services related to the XDG portal disappeared (after restarting both of them).
However, the XDG Desktop Portal service itself is reporting that no backend was found: xdg-desktop-portal[7132]: No skeleton to export.
I already mentioned that even if you don’t use Flatpaks, you can still encounter problems with other apps, like browsers. The backend is easy to choose when you have the default DE: if it’s GNOME, then xdg-desktop-portal-gnome; if it’s KDE, then xdg-desktop-portal-kde. These are usually installed automatically if you have installed one of default DEs. I would install the GTK backend (xdg-desktop-portal-gtk). Why? For example, Firefox depends on GTK, and I also use GIMP, which depends on GTK. In general, GTK will be completely enough for me. But please note, some Flatpaks depend on other services that require a specific backend, like GNOME for XDG Desktop Portal. If a Flatpak doesn’t work with GTK, you’ll have to check the logs to figure out what it needs and install it if necessary, possibly another backend.
$ sudo apt install xdg-desktop-portal-gtk
NB! You need to understand this sequence in order to decide how and when to launch the aforementioned services (wireplumber and xdg-dektop-portal).
The wireplumber service manages the sound server pipewire sessions.
If you enable it with systemctl --user enable wireplumber, it will start automatically on boot.
However, you cannot enable xdg-desktop-portal service in the same way! Moreover, even if you can do it manually, keep in mind that it will result in an error without the DISPLAY environment variable, just like dunst in the previous article.
So, I do not enable wireplumber because it will need to be restarted after xdg-desktop-portal is launched. Instead, I modify the bspwmrc config, so it handles it for me.
I add these lines (systemctl --user start xdg-dektop-portal,
systemctl --user restart wireplumber and systemctl --user restart pipewire):
$ sudo vim.tiny /etc/xdg/bspwm/bspwmrc
#! /bin/sh
#SXHKD Launching
pgrep -x sxhkd > /dev/null || sxhkd -c "/etc/xdg/bspwm/sxhkdrc" &
#DISPLAY env import
systemctl --user import-environment DISPLAY
#Starting XDG Desktop portal
systemctl --user start xdg-dektop-portal
#ReStarting Wireplumber
systemctl --user restart wireplumber
systemctl --user restart pipewire
#DUNST Launching
systemctl --user start dunst
#POLYBAR Launching
polybar-msg cmd quit
echo "---" | tee -a /tmp/polybar.log
polybar 2>&1 | tee -a /tmp/polybar.log & disown
bspc monitor -d I II III IV V
bspc config border_width 2
bspc config window_gap 12
bspc config split_ratio 0.52
bspc config borderless_monocle true
bspc config gapless_monocle true
You can do sudo reboot and then startx to check the success of modifications with:
systemctl --user status wireplumber systemctl --user status xdg-desktop-portal and systemctl --user status pipewire. Here is what I have:
Everything seems alrighty!
Time to test Bluetooth!
$ bluetoothctl
[bluetooth]# scan on
[NEW] Device XX:XX:XX:XX:XX:XX MAJOR IV
[bluetooth]# pair XX:XX:XX:XX:XX:XX
Attempting to pair with XX:XX:XX:XX:XX:XX
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
[CHG] Device XX:XX:XX:XX:XX:XX Bonded: yes
Pairing successful
[bluetooth]# connect XX:XX:XX:XX:XX:XX
Attempting to connect to XX:XX:XX:XX:XX:XX
Connection successful
[MAJOR IV]# scan off
Connection successful! Start enjoying Public Memory - Zig Zag.
Now I can use the WirePlumber CLI to check if the device is registered there.
➇ Pipewire audio profiles: Understanding the difference between device profile headset-head-unit and a2dp
$ wpctl status
PipeWire 'pipewire-0' [0.3.65, alisa@wonderland, cookie:1612476836]
└─ Clients:
...
Audio
├─ Devices:
│ 39. GA106 High Definition Audio Controller [alsa]
│ 40. Built-in Audio [alsa]
│ 51. MAJOR IV [bluez5]
│
├─ Sinks:
│ 41. Built-in Audio Digital Stereo (IEC958) [vol: 0.40]
│ * 52. MAJOR IV [vol: 0.60]
│
├─ Sink endpoints:
│
├─ Sources:
│ 42. Built-in Audio Analog Stereo [vol: 1.00]
│
├─ Source endpoints:
│
└─ Streams:
...
Sinks are audio output devices, and sources are audio input devices. As you can see, wpctl status shows that my Marshall headset is registered as a sink (so, output) and not as a source, so I can't use the microphone of my headset.
wpctl is similar to pactl, which is the PulseAudio CLI. However, you can use it with PipeWire without installing the PulseAudio server—just the utilities. So, I’ll do that because pactl is easier to use for me. pactl list output will help me explain why my headset is attached only as an output device.pactl is part of the pulseaudio-utils package.
$ sudo apt install pulseaudio-utils
$ pactl list
Card #52
Name: bluez_card.XX_XX_XX_XX_XX_XX
Driver: module-bluez5-device.c
Owner Module: n/a
Properties:
....
api.bluez5.connection = "connected"
api.bluez5.device = ""
bluez5.auto-connect = "[ hfp_hf hsp_hs a2dp_sink ]"
...
device.alias = "MAJOR IV"
device.api = "bluez5"
device.bus = "bluetooth"
device.description = "MAJOR IV"
device.form_factor = "headphone"
....
Profiles:
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
a2dp-sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 16, available: yes)
headset-head-unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 1, available: yes)
a2dp-sink-sbc: High Fidelity Playback (A2DP Sink, codec SBC) (sinks: 1, sources: 0, priority: 18, available: yes)
a2dp-sink-sbc_xq: High Fidelity Playback (A2DP Sink, codec SBC-XQ) (sinks: 1, sources: 0, priority: 17, available: yes)
headset-head-unit-cvsd: Headset Head Unit (HSP/HFP, codec CVSD) (sinks: 1, sources: 1, priority: 2, available: yes)
headset-head-unit-msbc: Headset Head Unit (HSP/HFP, codec mSBC) (sinks: 1, sources: 1, priority: 3, available: yes)
Active Profile: a2dp-sink-sbc
Input is quite long, but you just have to find the card of your audio device. What’s important in the output are the profiles. For my Marshall IV headset, the available profiles (which my Marshall supports, and as I mentioned above, it’s not the highest-end codec it supports in terms of quality) are a2dp-sink (only output), a2dp-sink-sbc (only output), a2dp-sink-sbc_xq (only output), headset-head-unit (both input and output) and headset-head-unit-xvsd (both input and output).
Active Profile: a2dp-sink-sbc
a2dp-sink-sbc: High Fidelity Playback (A2DP Sink, codec SBC) (sinks: 1, sources: 0, priority: 18, available: yes)
You can see that there are no sources for this profile, only sinks! So, THIS IS THE REASON WHY I can use my Marshall only as an output device.
However, I am not bound to only one codec, automatically selected. I can switch it.
$ pactl set-card-profile bluez_card.XX_XX_XX_XX_XX_XX headset-head-unit
#I can change it back
$ pactl set-card-profile bluez_card.XX_XX_XX_XX_XX_XX a2dp-sink-sbc
NB! When I use the profile headset-head-unit to use the microphone, the sound quality is quite horrid. I guess this is connected to the maturity of PipeWire and the overall performance of Bluetooth audio devices on Linux, which is evolving rapidly but still has room for improvement. You can tweak the configuration, and if I find a solution to improve the audio quality, I will definitely share it. Most likely, it will be related to the configuration of PipeWire
(Optional)
Upgrading the PipeWire sound server version could be a partial remedy. For Debian Bookworm, the way to upgrade it is through the Bookworm backports:
#add bookworm-backports repo
$ sudo vim.tiny /etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free
$ sudo apt update
$ sudo apt install --reinstall -t bookworm backports pipewire-audio
That's all! See you in the next, conclusive part, which will be dedicated to having fun with Polybar, shell cuxtomization and installing some cool apps.
Top comments (0)