[HN Gopher] PipeWire: Bluetooth Support Status Update
___________________________________________________________________
PipeWire: Bluetooth Support Status Update
Author : mfilion
Score : 94 points
Date : 2022-04-29 16:26 UTC (6 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| ComputerGuru wrote:
| I've only heard good things about PipeWire so I must ask: will
| this finally give me a lower latency option for Bluetooth audio
| on Linux? After my old Anker speakers went belly-updeg I
| "upgraded" to their latest model which I didn't realize was
| aux/3.5mm-free and have been suffering ever since from horrendous
| lag when using the external speakers to stream movies on my Linux
| laptop.
|
| deg Ok, in actuality my kid broke half a male 3.5mm connector in
| the speaker's 3.5mm female port and I was too lazy to break it
| open and solder in a replacement. Mostly due to not wanting to
| hunt for a layout-compatible female 3.5mm jack.
| rektide wrote:
| 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 the
| basics on how available this is right now.
|
| But that should not affect your use case; playing movies should
| work fine, period, end of statement. The fact that there is
| latency to your speaker is something that an bluetooth or other
| audio pipeline should know, should be able to compensate for.
| PulseAudio (which your music players are almost certainly
| using, under pipewire or other) has great understanding of
| latency built in. If you do experience big audio latency, open
| up pavucontrol & adjust your device's latency, and that problem
| should go away. It should be semi-stable. But pulseaudio &
| pipewire both should, in a wide range of cirumstances,
| understand what the expected latency is & "just work."
|
| If you are on a videoconference, however, knowing that there's
| a second of latency doesn't help, won't bring things closer to
| real-time. It's still gonna be terrible. Newer specs, newer
| codecs could help significantly, but the audio daemon won't be
| able to help. Pulseaudio did have higher latency by default,
| tuneable (i think i'd tuned to using 2 frames of 16ms each =
| 32ms, pretty aggressive), but I think they've trimmed it
| significantly in very recent releases, but pipewire's
| architecture has allowed it to be significantly more
| aggressive.
| adamomada wrote:
| 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.
| ace2358 wrote:
| I just use vlc and the s and d keys I think for adding audio
| offset either slow or fast!
| viraptor wrote:
| Yes, it doesn't remove the latency completely, but it's the
| best we've got now. I'm using a Bose soundbar and the Bluetooth
| connection is way too laggy for movies on pulseaudio, windows,
| or Mac. Pipewire was great and usable with default settings. In
| an ironic twist, Linux has the best audio story of all systems
| right now.
| Filligree wrote:
| Lower latency is one of the design goals for Pipewire, so
| almost certainly yes. How _much_ lower latency may be a
| different matter.
| ComputerGuru wrote:
| I've been wanting to experiment with some hard-coded low-
| level (asm/C/rust) Bluetooth on a microcontroller to
| experimentally/empirically determine the lowest possible
| Bluetooth audio delay for some time (getting rid of all
| encoding, context switching, garbage collection, etc etc
| overhead). ~~I think~~ it's fundamentally a laggy approach to
| audio streaming because of the packetization that takes
| place, but it shouldn't be to the extent that it is so
| immediately noticeable.
| ajsnigrutin wrote:
| Was latency ever an issue with movies? I know mine works
| without issue on pulseaudio+bluez by delaying the video to sync
| it with audio (which is actually noticable with an old noname
| speaker when you pause/play the video - the video stalls, then
| (i guess) the audio buffers are filled, and movie starts
| playing with syned a/v, and then when pausing, maybe half a
| second of audio is still played after you've paused it).
| ComputerGuru wrote:
| Definitely an issue with Netflix on Ubuntu. Enough that I
| prefer to "obtain" via other means the content I have paid
| access then watch it in mpv (where I must still manually
| introduce a video delay).
|
| The delay you describe should be only as long as it takes for
| the audio packet to be processed by the audio stack as the
| video syncs with the audio and not the other way around. But
| I don't think Bluetooth blocks for an ack of each packet (and
| if it did, you'd be delayed the other way because of the time
| it takes for the response to reach after the packet has
| finished playing)!
|
| The half second of audio playing after you pause can be
| explained by the same delay I describe: that's how long of a
| lag there is between source and sink (like you say, due to
| buffering - plus the transmission delays).
| Adverblessly wrote:
| > Definitely an issue with Netflix on Ubuntu. Enough that I
| prefer to "obtain" via other means the content I have paid
| access then watch it in mpv (where I must still manually
| introduce a video delay).
|
| pavucontrol let's you introduce a delay per device (in
| Output Devices under "Advanced" for the specific device),
| which might allow you to use it with Netflix directly. Or
| at least I managed to get it working wonkily once and then
| went back to using mpv...
| spacemanmatt wrote:
| Since I switched to pipewire I've had the best Linux audio end-
| user experience with BlueTooth devices, ever.
| silentprog wrote:
| Same, also seamslessly connecting to my headphones while before
| I had to unpair and pair the whole time.
| kaladin-jasnah wrote:
| 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.
| smoldesu wrote:
| 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!
| adamomada wrote:
| 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
| christophilus wrote:
| I have found my vanilla Fedora install to have a better
| Bluetooth experience than my Mac did. That's quite a feat.
| emerongi wrote:
| 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.
| colordrops wrote:
| Ironic, I just upgraded my NixOS system which uses PipeWire and
| now my Bluetooth headset has gotten really flakey for video con
| calls. It's not that audio is broken, but something has changed
| with PipeWire where it no longer uses the right audio device for
| output and input and I have to fiddle for a few minutes now
| before every call. Haven't figured it out yet.
| heavyset_go wrote:
| Are you using WirePlumber and pipewire-pulse?
| colordrops wrote:
| 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.
| colordrops wrote:
| I don't know, I'll look into it. I assume pipewire-pulse is
| in use because it works with all the pulse tooling.
| heavyset_go wrote:
| 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.
| ubercow13 wrote:
| I found when Fedora switched to wireplumber it made
| bluetooth much less reliable. Every time I connected my
| headphones I had to restart wireplumber multiple times
| for them to connect. Haven't tried it for a few months
| though, maybe it's improved.
| maxerickson wrote:
| Yeah, I've just been restarting the pipewire service
| instead of looking into it, but I started having audio
| output fail when I switched to wireplumber.
| ahartmetz wrote:
| Wireplumber looks much more wonky to me than media-
| session, so I'm deferring the switch for now.
| Wireplumber's design seems flashy and not guided by
| experience or good taste to me, the opposite of Pipewire
| proper.
| 4khilles wrote:
| I have the same issue on the latest Fedora. It's very
| disappointing that bluetooth connectivity isn't a solved
| problem in 2022 (at least on Linux, haven't noticed any
| issues in Windows for a while). Are we ever going to get
| to a point where bluetooth "just works"?
| TobTobXX wrote:
| Relevant XKCD: https://xkcd.com/2055/
| R0flcopt3r wrote:
| I have daily bluetooth issues on Windows. Someone decided
| it was a good idea to have bluetooth jabra
| speakers/microphones for our meetingrooms... It takes 5
| minutes to do the pair/connect/set correct device
| dance... every. day.
|
| My macbook can't even figure out that it should try to
| connect to my offce trackpad after I have had it
| connected to my home trackpad! Thankfully it has a built
| in trackpad that I can use to manually connect when the
| "automation" fails..
| 0xbkt wrote:
| 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.
| sph wrote:
| It does. I haven't tested it personally but AFAIK PipeWire does
| switch automatically to the best codec when you're not using
| the mic.
| rektide wrote:
| Bluetooth continues to be one of the most critically under-
| delivered standards, in my view. LC3, that this update discusses
| at the end, was announced January 2020. Over two years ago.
| There's still, to my knowledge, no devices that support it. None,
| not a one.
|
| In general I feel like we only just got Bluetooth 5.0 devices
| available on computers. Bluetooth 4.0 or 4.2 has been
| frighteningly prevalent, until very very recently. Bluetooth 5
| harkens back to mid 2016, Bluetooth 5.1 was announced January
| 2019, 5.2 in January 2020, 5.3 (you guessed it) 2021, but I'd
| wager you'd need to drop numerous significant figures below 1% to
| account for how many laptops (much less desktops) are sold today
| whose bluetooth is >5.0.
|
| Truly one of the slowest, laggiest, least adoptable technologies
| on the planet. Really weird to me.
|
| I can definitely accept some lag. LC3 is really using bluetooth-
| le, a very different scheme. At the same time, I see folks like
| zephyr-project already kind of making inroads into this
| future[1], in the open. A not small part of me thinks the way we
| do consumer devices is totally jank. That folks like PineBuds are
| living in the future, where we can compile our own OS'es for our
| peripherals. PineBuds[2] could, with a little zeal & push, become
| the first LC3 device on the planet. And they could, perhaps,
| unlike most other devices that'll be made in the next couple
| years, possibly support whatever comes next.
|
| Shifting areas of interest a bit, but: another data-point in
| opening the future, the software Intel uses for their new PSE
| management engine just got open sourced[3]. It too is built on
| Zephyr.
|
| On the positive-side, for PipeWire, incredibly sweet to see
| Hands-Free Profile get better. This is essentially the idea of a
| computer acting like a headset. This enables such vast additional
| degree of system flexibility, creates so many interesting
| situations. Phones, cars, other things are very limited in what
| they can do. But if we can wirelessly plug in a general purpose
| computer, make it act like audio system: we can do so much more.
| The old Nohands[4] stack is wildly out of date & unsupported.
| PipeWire just doing the thing is 100% super sweet as the world
| needs to be. In general, a more amorphous world where computers
| can act as hosts or devices is one I thing would be vastly
| empowering: software is soft, and so too should be hardware, when
| it can.
|
| [1] https://github.com/zephyrproject-rtos/liblc3codec
|
| [2] https://www.pine64.org/2022/04/01/introducing-the-
| pinebuds-a...
|
| [3] https://news.ycombinator.com/item?id=31121264 (2 points, 7
| days ago, 0 comments)
|
| [4] http://nohands.sourceforge.net/
| lxgr wrote:
| > Over two years ago. There's still, to my knowledge, no
| devices that support it. None, not a one.
|
| To be honest, that timeline strikes me as pretty comparable
| with other hardware protocols like 802.11, USB, 5G etc. These
| are complex protocols, parts of them implemented in fixed-
| function logic, and that just takes some time to market.
___________________________________________________________________
(page generated 2022-04-29 23:00 UTC)