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.
PipeWire: Bluetooth Support Status Update
71–80 of 101 posts
Re: PipeWire: Bluetooth Support Status Update
#72PipeWire is great (and so were PA and Alsa and OSS in their time) and I hope the PipeWire's end-user documentation will be improved, so that I can use wireplumber instead of pipewire-media-session. Right now the end-user story is still a bit rough.
Re: PipeWire: Bluetooth Support Status Update
#73I had choppy audio when under high CPU load on older hardware with PipeWire, but got told that increasing the latency prevents that. The reason I don't get that with PulseAudio is that it has higher latency than PipeWire's default latency. Turns out this command works for me: pw-metadata -n settings 0 clock.force-quantum 2048
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.
Re: PipeWire: Bluetooth Support Status Update
#74Earlier quoted context omitted.
So is pipewire actually valuable and not just pulseaudio all over again?
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.…
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...
Re: PipeWire: Bluetooth Support Status Update
#75Earlier 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)
> I might need a little more convincing
What about you give it a try instead?
Re: PipeWire: Bluetooth Support Status Update
#76I had choppy audio when under high CPU load on older hardware with PipeWire, but got told that increasing the latency prevents that. The reason I don't get that with PulseAudio is that it has higher latency than PipeWire's default latency. Turns out this command works for me: pw-metadata -n settings 0 clock.force-quantum 2048
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…
Fedora has started considering the switch to a fully preemptible kernel.
Re: PipeWire: Bluetooth Support Status Update
#77Earlier quoted context omitted.
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.
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 doin…
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.
Re: PipeWire: Bluetooth Support Status Update
#78Re: PipeWire: Bluetooth Support Status Update
#79Earlier 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)
Nice of you to dismiss people’s (mostly a single one’s) free work.
Re: PipeWire: Bluetooth Support Status Update
#80Earlier quoted context omitted.
There are protocol limitations here. There have been very recent advances, that bring us to 40~60 ms, but they all root in Bluetooth 5 (officially announced july 2016 but holy fucking shit this adoption has been trashfire slow especially on pc) and it's incredibly confusing/difficult to understand which if any codecs have been able to take advantage of this possibility. It'd take me probably an hour to put together t…
I’m not certain Bluetooth 5 is it: I have a MacBook Pro 2012 w Bluetooth 4.0. Using it with two Bluetooth devices results in different latency, depending on the device. JBL “true wireless” I have to adjust audio to about -200 ms delay while with AirPod pro I don’t have to make any adjustment. Both the JBL and Apple devices are Bluetooth 5.
Well they can't use Bluetooth 5 since your MBP only has 4.
Bluetooth 5 isn't the savior though. My Bose Quietcomfort Earbuds have tremendous lag even attached to Bluetooth 5+ devices like my phone or desktop.