Hacker News Reader

Comment by chenxiaolong | Hacker News Reader

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).

View on HN

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'

[0] https://wiki.archlinux.org/index.php/Pipewire#Audio

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!

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)

Did you get 2—way (in & out) 16khz Bluetooth to work? Am I right that this isn't possible?

I believe when the HFP profile is used and mSBC is supported, then mSBC is used for both the input and output.

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.

There's some work on getting AVRCP absolute volume implemented here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/46...

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).

In `/etc/pipewire/media-session.d/bluez-monitor.conf`, I uncommented:

    bluez5.msbc-support = true
    bluez5.sbc-xq-support = true

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".

[1] https://patchwork.kernel.org/project/bluetooth/patch/2020121...

Would there be improvements for remote audio streaming over pulseaudio with ssh?

I'm not sure about this one. I haven't tried streaming audio over the network with either pulseaudio or pipewire.

It appears Fedora 34 (next version) will make it default.

Why would this affect bluetooth codecs?

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.

For example, this is the PR that enabled mSBC support for the HFP profile: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_req...

Is that X11 or Wayland?

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.

This was all with Wayland. I haven't tried using pipewire with X11.

Reply on news.ycombinator.com