Hacker News Reader

Comment by spacemanmatt | Hacker News Reader

Since I switched to pipewire I've had the best Linux audio end-user experience with BlueTooth devices, ever.

PipeWire supports the most audio codecs of any desktop operating system, period. Windows and Mac don't have LDAC, Mac doesn't have aptX, etc.

Definitely, having just bought some XM4s I was kinda taken aback by having LDAC automatically pop up in my audio settings. Very neat to see support being that seamless!

I vaguely remember an old post from here showing someone hacking up Bluetooth to give SBC codec better quality, and it only being available on Linux (or maybe it was Linux+Android?)

I’ll try to dig it up and edit it in here, as I think it was a great hack

Do you mean mSBC?

I found a couple links, since I remembered that Zenwalk distro was one of the first to include it. They call it SBC XQ

[0] http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc...

Via

[1] http://www.zenwalk.org/2019/09/audio-quality-of-sbc-xq-bluet...

I have found my vanilla Fedora install to have a better Bluetooth experience than my Mac did. That’s quite a feat.

A bit offtopic, but having received a Mac for work recently, I have come to appreciate Fedora and Gnome so much more. Throughout the years I've heard people rave about Apple and I honestly think Gnome is better. The only argument against Linux at the moment is the app ecosystem.

This is true.

Apple still is more sophisticated in the desktop scripting department. Applescript support in most applications and the ability to tie that into actions is seriously powerful stuff.

Gnome wins in the ability to use javascript to customize window handling, but it isn't really able to script application actions like you can in OS X.

It is improving though. If you can use keyboard to navigate the functions you want in applications you can automate it with software like keymapper.

https://github.com/houmain/keymapper

There are other similar software available. Probably a half a dozen serious projects in total.

Keymapper is software that intercepts input from your keyboard and allows you to 'remap' it. It operates on the libinput level of things, so it works regardless of environment or if you are in the console. It does require elevated privileges, though.

This, when combined with Gnome-shell extension and user keymapperd daemon can provide application-specific contexts for keyboard combos. The extension monitors for switching applications and gives keymapper the ability to be context-aware.

This is how I "solved" the copy past nightmare for myself in Linux. This way no matter if I am in a browser, terminal, or Emacs I have consistent copy-paste keys. (super-c, super-v). Makes things easier.

This isn't even remotely on the same level as applescript, but at least it is something. You have to understand low-level Linux keyboard stuff, which is still a mess. Versus being able to simply record yourself using applescript.

Gnome certainly is a very relaxing environment once you get used to it. Much less frantic or distraction filled compared to Windows or OS X. I like it.

I think Fedora is way underrated. They let Gnome do it’s thing in terms of the look and feel, and focus on bringing other tech into the desktop fold. They did this with Wayland, Flatpak and Pipewire, bringing them into a major stable distribution before any other equivalent distro did.

And personally, I think Gnome is absolutely awesome. If Desktop Linux has any hope of succeeding, it needs exactly what Gnome is doing. A stable UI API that developers can develop apps towards.

Gnome devs got so much flak for getting rid of theming/customization (they haven’t gotten rid of it, but they’ve made it much harder by default), but the reality is that it’s what’s made it possible for Gnome to implement real Dark mode so effectively.

I just updated my Ubuntu to 22.04 and absolutely love all that Gnome has brought to the table (sure Ubuntu added accent colors, but Gnome will likely get that within months).

I think the Fedora + Gnome combo is just brilliant and will potentially make the year of Linux on the Desktop actually achievable.

The dark mode handling has been the worst thing about Gnome for a long time, only getting worse with GTK4. I fondly remember some apps not accepting any global dark mode setting, only having a toggle in their own settings. Having switched to KDE since, it's nice to know the situation has seemingly improved.

In my experience, Bluetooth on the Mac is not great (especially if you aren't willing to exist solely in Apple-land).

Windows, with the right BT card/drivers (usually anything Intel) is the best, with Linux a close second, but some of the other vendors have very sketchy Bluetooth support.

So is pipewire actually valuable and not just pulseaudio all over again?

While not perfect yet (it's still a relatively young project) it works as good or better than pulse in most general usage scenarios and avoids a lot of nonsense that you used to have to go through with using jack audio in tandem with pulse as well.

For the most part it works out of the box with good latency without extra configuration and provides good routing options as well for more advanced usage.

Pipewire implements the APIs of Pulse, Alsa, and Jack. So instead of having to juggle between them all, you just have one service to manage and it all just works.

It only took a few lines for me to switch and I've never had a Linux audio issue ever since! (And when I have, it's been my fault like my volume was turned down or my speakers were unplugged lol)

How did you switch? I'd be interested in trying this on Ubuntu.

Should be pretty close -

https://wiki.debian.org/PipeWire

Thanks!

Apparently this is already running on my Ubuntu 21.10, I wonder if they switched over from the default. I've had no problems with BT at all, it just works. I wonder if that's why.

I made the switch this morning by following this: https://ubuntuhandbook.org/index.php/2022/04/pipewire-replac...

So far the only anecdotes I have are (a) everything seems to be working and (b) don't forget to reboot after installation.

Ah, thanks!

Very much. It's more like Jack all over again, but more friendly - than pulseaudio.

Pulseaudio had to contend with a huge number of buggy drivers, adapters, and clients. The bugs very gradually got fixed under pressure from PA, with PA always blamed. (PA of course also had bugs that gradually got fixed.) PW benefits from the more sane operating environment PA enforced.

I always used to delete PA because I had no desire or need ever to have more than one audio source feeding more than one audio sink. We don't live in a world compatible with that model anymore.

Going to be very real, I do not really have more than an inkling of the "world" PW inherits or whatever, but this sounds like "trust us, this time it's okay." I might need a little more convincing this isn't just another attempt to recreate a "universal framework that covers everyone's use cases." (I won't like the obvious reference)

> I might need a little more convincing

What about you give it a try instead?

Nice of you to dismiss people’s (mostly a single one’s) free work.

I am not dismissing anyone's work. By this logic, the pipewire folks are dismissing ALSA and pulseaudio's work, which is equally absurd.

> the pipewire folks are dismissing ALSA and pulseaudio's work

That is just not true. PW uses ALSA for physical output and it implements PA so that all the apps just work. There is nothing dismissive about that.

That notion might seem plausible, but the author of Pipewire witnessed the entire PulseAudio process, so has strong motivation not to repeat its reception, and plenty of hindsight to help.

Notably, the developer of Jack, the universally admired professional audio system, now uses PipeWire via its Jack-compatible API. He is frequently here on HN.

You should read up on what PipeWire is before you talk trash about it and start implicating it in some catastrophic repeat of PulseAudio that you just made up.

From what I've read, PA did expose a lot of driver bugs, but this was mostly caused by it rewinding audio buffers [0], a driver feature that was not commonly used before PA. PW doesn't use rewinding though.

[0] https://www.freedesktop.org/wiki/Software/PulseAudio/Documen...

It's fine when it works. It's a monstrosity when it doesn't.

I spent an hour the other day trying to figure out how to tell it not to output audio through my DualSense controller haptics (which look like a four-channel audio output) when I connect it to an Intel NUC over USB. I never did succeed, and all the posts I found were basically other people asking how to do similar things.

I used pavucontrol to simply tell it to not do it. Once is enough.

In the sound cards list, just set to disabled.

You can't use `pavucontrol` unless you're logged in to a graphical interface as the user who is producing the sound.

For a headless system, it's useless.

`pactl` is the command line version

And 'ssh -X' is also a thing.

Also tried, also useless. The program producing the sound is being run by another user.

>For a headless system, it's useless.

DualSense is a game controller. In this context, headless is unlikely.

Depends on how you define headless, but the fact is, I'm rarely logged into it, and there's no mouse nor keyboard connected, nor any X server running.

you can actually use pavucontrol for remote PA servers that have native-protocol-tcp running

$ PULSE_SERVER=192.168.1.21 pavucontrol

Pipewire is able to handle LDAC on my Bluetooth headset and switch to mSBC to behave as a headset and use the headset as a wireless input device. It's awesome! Never had instability or glitches, even when you make complex audio changes and can almost feel the gears grinding. It hasn't let me down!

Same, also seamslessly connecting to my headphones while before I had to unpair and pair the whole time.

Reply on news.ycombinator.com