Live data from Hacker News

PipeWire: Bluetooth Support Status Update

collabora.com

91–100 of 101 posts

Re: PipeWire: Bluetooth Support Status Update

#91
post #50

Earlier quoted context omitted.

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

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)

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.

Re: PipeWire: Bluetooth Support Status Update

#92

Earlier quoted context omitted.

Are you using WirePlumber and pipewire-pulse?

Previous response is too old to edit. Looks like NixOS's pipewire service enables WirePlumber by default. Not sure if it changed recently from media-session, and that's why it's gone unstable, or if it's something else.

When I was futzing around two or three months ago with audio on my NixOS system I believe it was still using media-session. Are you on unstable? I believe the intention was to migrate to WirePlumber, but didn't expect that to happen already.

Re: PipeWire: Bluetooth Support Status Update

#93
post #73
post #65

Earlier quoted context omitted.

PipeWire will use SCHED_RR automatically, but Linux mainline is pretty bad at actually delivering consistently low scheduling latency. As an alternative to increasing latency, especially if you're not running on batteries, try linux-rt. (PREEMPT_RT). It makes scheduling latency decent. On my machines, the max column in rt-test cyclictest, after running for a day, remains at linux-rt patchset is slowly getting merged…

Debian has Linux RT builds, so I could use those, but really the change in quantum isn't noticeable at all. I just need to figure out how to configure pipewire to keep it at that value instead of reverting after restarts.

With its 30ms scheduling latency peaks (guaranteed xrun), I've found mainline is simply not capable of audio in any reasonable form.

If you do audio at all and run Linux, I can't recommend PREEMPT_RT enough.

Re: PipeWire: Bluetooth Support Status Update

#94
post #87

I’m really interested in pipewire for use with AirPods, I really want to be able to leverage wireless comms for voice. Does the current state support AirPods well? Sorry if that’s obvious but I’m under the impression the AirPod codecs are slightly different to non apple headphones.

Airpods should work fine, probably defaulting to AAC.

Thanks, it turns out I had pipe wire installed, and mic quality was good. I’m unsure if as good as on my phone but good enough for meetings!

Re: PipeWire: Bluetooth Support Status Update

#95

Earlier quoted context omitted.

Previous response is too old to edit. Looks like NixOS's pipewire service enables WirePlumber by default. Not sure if it changed recently from media-session, and that's why it's gone unstable, or if it's something else.

When I was futzing around two or three months ago with audio on my NixOS system I believe it was still using media-session. Are you on unstable? I believe the intention was to migrate to WirePlumber, but didn't expect that to happen already.

Yeah I'm on unstable, and it's indeed using WirePlumber now. That must have been the change that destabilized things, thanks.

Re: PipeWire: Bluetooth Support Status Update

#96

Earlier quoted context omitted.

I don't know, I'll look into it. I assume pipewire-pulse is in use because it works with all the pulse tooling.

Yeah, if it works with the PA tools, then you're using pipewire-pulse. If you aren't using WirePlumber, try it out, as pipewire-media-session doesn't work as well and is more of a reference implementation than an end-user product.

It turns out that Nix Unstable switched from media-session to WirePlumber recently and that is the source of the instability I'm seeing. Perhaps it's not yet configured properly in Nix.

Re: PipeWire: Bluetooth Support Status Update

#97
post #79

Earlier quoted context omitted.

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.

Re: PipeWire: Bluetooth Support Status Update

#98
post #50

Earlier quoted context omitted.

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

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)

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.

Re: PipeWire: Bluetooth Support Status Update

#99
post #30

I was never successful in getting both mic and HQ audio working with BT on PulseAudio. Configuring to use A2DP gives the most fulfilling sound quality while nullifying the mic, thus becoming a huge deal-breaker for me. Does PipeWire incorporate any wizardry to overcome this and let me have simultaneous access to both mic and high quality audio? I have a JBL Everest Elite 700 and I am running on Ubuntu 21.10.

AFAIK the best you can do is mSBC (if the headset supports it). It is still not high quality though and as I understand it this is a general Bluetooth limitation.

Re: PipeWire: Bluetooth Support Status Update

#100
post #57
post #41

Earlier quoted context omitted.

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.

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.

Post reply on HN