I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it:
* My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile.
* Higher quality A2DP stereo codecs, like LDAC, also work.
* AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.
* DMA-BUF based screen recording works with OBS + obs-xdg-portal + pipewire (for 60fps game capture).
For my use cases, the only things still missing are automatic switching between A2DP and HFP bluetooth profiles and support for AVRCP absolute volume (so that the OS changes the headset's hardware volume instead of having a separate software volume).
If you use Arch Linux, it's really easy to just drop this right in from official packages as a replacement for Pulse/ALSA [0] and start using it. I've been running it for about a month and everything seems to work exactly as I expect it to. I honestly notice no difference other than the pulse audio input/output picker extension I had been using seems confused now (the native GNOME sound control panel applet works just fine though).
On the video front I use obs-xdg-portal for Wayland screen capture as well - finally there's a good story for doing this! You even get a nifty permission dialogue in GNOME. You have to launch OBS in forced wayland mode with 'QT_QPA_PLATFORM=wayland obs'
Interesting... I had the exact opposite experience just a few days ago. After multiple reboots, reinstalls, deleting all configs and every other troubleshooting step I could think of, pipewire-pulse still showed no devices whatsoever. Switching back to pulseaudio brought everything back immediately.
As for xdg-desktop-portal screensharing, while I'm glad to see at least some standard way of screen capture on Wayland and in theory, permissions are cool, it's still a bad situation. Because each window capture needs explicit permission, dynamically capturing windows is basically impossible and proper movable region capture is tedious and confusing at best. (also d-bus just feels...grosss..but that's obviously very subjective)
Thanks for this, I was wondering if a future Arch update would just auto install this and I would be left wondering what happened when it broke. I am going to remember your post here and try to upgrade to it soon!
What in particular do you want/ expect from AVRCP here?
I can't tell, but it sounds like the two things it might do for me are:
1. Allow my software stack to remember and restore levels on a hardware device, so maybe my big on-ear headset is super loud compared to the cheap earbuds I use, lets have the software notice they're different and put the hardware output levels back where they were on each device when it sees them. This avoids the device (which presumably is battery powered) needing to correctly remember how it was set up. I would like this.
2. Try to avoid noise from analogue amplifier stages in the headset by only using as much amplification as is strictly needed for current volume settings, which in turn involves guessing how linear (or not) that amplifier's performance is, or makes my level controls needlessly coarse. I don't want this, I'll put up with it but mostly by finding settings where it's not too annoying and swearing every time it trips up.
For me, I'd like/expect pipewire to lock the software volume at 100% and adjust only the hardware volume if AVRCP absolute volume is supported by the head. (This seems to be how Android and Windows behave.) I mainly care about keeping everything in sync so that no matter if I adjust the volume using the keyboard, GUI volume slider, or buttons on the headset itself, it'll always behave the same. A lot of the time, I end up needing to hit both the volume up keyboard shortcut and the volume up button on my headset because one of the two is already at the max.
I believe your first point should automatically work once this is implemented. Pipewire seems to already support remembering the volume per bluetooth device (though it's just the software volume that's being remembered right now).
"My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile."
What configuration did you have to do to get this to work? I'm also using pipewire built from the latest master (PipeWire 0.3.22).
You'll also need to make sure you're on a kernel supporting the WBS fallback patch[1], which should be the case if you have the latest 5.10 kernel or the 5.12 development kernel.
You can check if it's working by running `info all` in pw-cli. It'll mention if the bluez codec is "mSBC".
I'm not super familiar with the pipewire internals, but I believe pipewire is the daemon responsible for talking to bluez/bluetoothd and ensuring that the audio stream is encoded with a codec that the headset supports.
I just installed Pipewire in Arch Linux running GNOME on Wayland, and I finally have working screensharing in Firefox: I can share e.g. GNOME Terminal (a Wayland-native non-Xwayland app) in a video meeting, which I wasn't able to do without Pipewire.
* My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile.
* Higher quality A2DP stereo codecs, like LDAC, also work.
* AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.
* DMA-BUF based screen recording works with OBS + obs-xdg-portal + pipewire (for 60fps game capture).
For my use cases, the only things still missing are automatic switching between A2DP and HFP bluetooth profiles and support for AVRCP absolute volume (so that the OS changes the headset's hardware volume instead of having a separate software volume).