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
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!
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 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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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 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!
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-up° 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.
° 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.
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.
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.
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.
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).
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).
> 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...
But the audio already arrives late compared to the visual part. To compensate for that, PulseAudio has to support time travel, while any video player "merely" has to delay the image sequence by a few frames to let it line up with the sound...
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.
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.
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.
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.
I've run into a similar issue, where the default output device wouldn't be selected, when I used PulseAudio by itself before Pipewire was a thing. I had to use one of the PA console mixers to set my default output and input devices, and with some playing around with it, I was able to make them the default. Might help to use pactl or one of the many PA mixers to poke around and see if there's anything you can adjust to fix the issue.
Might also help to test out pipewire-media-session to see if that helps, too.
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, 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.
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.
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"?
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..
I had a 12" MacBook no-adjectives in the past which didn't even work with AirPods well. I was hoping the M1 would have a better BT stack (the iPhone's...)
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.
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.
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.
Can someone explain to me what pipewire's goal is? to be a better pulseaudio? if so, in what way is it trying to be better? also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?)
why does it do video? is trying to do media capture like OBS or be a compositor like wayland? if so why bother? those solutions exist already... maybe it should just stick to audio, cuz that part of it feels like feature creep.
Pipewire is driven by the need to handle synchronized media from multiple sources delivered to multiple sinks in real time with minimal, constant latency. The reference problem is cars, which often have a dash cam, back-up cam, dash video display, instrument panel display, bluetooth phone connection, radio receiver, satellite receiver, audio amplifier, dash microphone, backseat video display with audio, seatbelt alarm, and more besides, that all have to be managed sensibly with minimal engagement.
Handling audio without video fails if they have to be kept in sync.
* (LAN-)devices, most a source/sink/control for various Audio/Video streams.
* Those devices (can) share/use any HW (Microphones/Speakers/V4L-devices) available
* programs producing/consuming sound/video, to be "exported" as individual sinks/sources
* Eventing support to dynamically change media routing
Your stated "reference problem" (Car AV) is (imho) not the most user-"relatable" scenario (after all, who has "hackable car"), a more common scenario I'd see:
* In several of the rooms of the dwelling there are
* Devices large/small with several connection types
* LAN (PCs, TVs, AV-HW, MediaPlayers, ...) with protocols including e.g.
* Well-known programs (VLC, KODI) with their "own" protocol
* UPNP/DLNA/AirPlay/Miracast/PulseAudio/RTSP/...
* SIP/WebRTC devices/clients (Doorbells, VoIP-Phones, VideoConf)
* Devices with Vendor-specific protocols. e.g LG WebOS
* USB connection to one of the above (WebCam, Android-devices, phones)
* Wifi-P2P (Some of LAN devices have this too, for e.g. screencasting)
* Bluetooth BTLE/Classic (devices can be stationary/mobile/transient)
I would like to enable these usecases:
* Send [emulated] [second] screen from PC to any Display surface
* View any desktop/UI/program/device on any other display surface
* Control all the above from PCs/Phones/Tablets, or Events (Doorbell -> Camera PiP @TV)
* Route any audio/video source to my speech-recognition/video-conf/VoIP Software
* Use Android device [connected to USB[ of another Device]] as 8+ devices: Camera F/R, Screen I/O, Audio I/O Headphone/Speaker/BT Microphone/App-Output
* Use "hook"-scripts for eventing/device control (TV might need some command to switch to HDMI3)
I realize most of the above can be probably be done using some GST/FFMPEG glue scripts/code and some systemd dependencies, but I'm haven't found quickly relatable examples of:
* "Run this command/config to add an ffpmeg commandline as virtual camera"
* "Use this config to represent your TV as another display output device"
* "Run this command On DevA to launch a GUI-binary on DevB, and make this "stream" available as VideoSource in Browser@DevA"
* "Use the Webcam on DevA, bluetooth headsets via DevB for input, TV1 as VideoOutput, AudioOut on AVR, runnings VideoConf on DevC"
* "Do this to implement access-control" (Bob can see Input "foo", but Alice can't)
Cars are a hard but representative problem, with intrinsic advantages:
- Multiple data flows
- Limited available attention
- Need for "just works"
- Need for trivial override
- Funding available
- Strong demand for solution
>Can someone explain to me what pipewire's goal is? to be a better pulseaudio?
Yes, and also the goal is to support video in addition to audio.
>if so, in what way is it trying to be better?
Well in addition to supporting video, it also supports jack clients without needing to run a separate server. There are a few other things like better security policies, but those are the major ones.
>also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?)
Pulseaudio's code is fine and pipewire is about the same, it's a relatively small core daemon with most of the major functionality split out into a large collection of loadable modules.
>why does it do video?
A few reasons, but the major one is because video on Linux has the same problem as audio: the low-level device API (V4L) can only be used by one program at a time. This leads to failures if you try to do something like access your webcam in two applications at the same time. Most applications should basically not be using ALSA or V4L directly to access devices for this reason. A sound server like pulseaudio is the typical way to mux/demux the audio devices to allow multiple applications to access it at once, and now pipewire extends that to video.
>is trying to do media capture like OBS or be a compositor like wayland?
Neither, it's used to route video sources between programs. Media players and cameras and Wayland compositors that want to do screencasting can send their video into pipewire; casting programs like OBS or any ffmpeg-based tools can receive any of these video streams from pipewire and do whatever they want with them, or could also output to pipewire so another program can consume their output. If applications support it then the idea is you'll be able to easily connect together any two applications that produce/consume video and it'll all just work.
>No, it isn't. Pulseaudio is based on a push model, which is completely broken.
These two statements are both very wrong. The push model is absolutely not broken, it's actually better for media players, networked sound and other non-pro-audio applications because it uses less power and can do more efficient buffering strategies. You're right that it's not good for pro-audio and other latency-sensitive applications, but pulseaudio was not designed to do that on purpose because jack already filled that niche. The pull model has to wake up every application every quantum on a strict deadline to do processing. In some situations pulseaudio should still be able to provide the smallest power usage compared to pipewire, even just continuing to use the pulseaudio API to do buffering on top of pipewire should be a benefit for applications that want it.
Even if it was broken (it's not), that would be an aspect of the design, not the code itself. The code itself is structured in mostly the same way as pipewire.
I 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:
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 <100µs, whereas if I use mainline it easily goes to ms range within a minute or two, and I've seen it go as high as 30ms.
linux-rt patchset is slowly getting merged into mainline. I am hopeful that at some point we will be able to build it with PREEMPT_RT, and that desktop kernels in distributions will do that.
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.
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.
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.
> 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.
> 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.
Bluetooth >= 5.2 and LC3 are some of the prerequisites of LE Audio, but LE Audio is a separate standard that builds upon them.
The Bluetooth has only finalised the core parts of the LE Audio standard 22/Mar/2022 [1].
Some optional parts of the standard, e.g. "TMAP: Telephony and Media Audio Profile" are still not finalised. [2]
Many of the phones that support Bluetooth 5.2 should be able to support LE Audio.
On the software side, Android 13 (expected Q3 2022) will be the first OS to fully support LE Audio, and that's a few months away.
It was indeed very poorly communicated, and there was poor expectation management, but within a few months all the pieces should come together and the first devices should appear.
Taking a year to deliver on your promise is ok. But it's well over 2 years and there is jack fucking shit, squada, naught, nothing, zilch. This is a super super super embarassing shit show, a disaster. If things were only just starting to show up, maybe, if adoption was slow, maybe, but literally no one adopting this? Yeahh no, this is a train-wreck technology. This particular organization is incompetent, is bound by their own bad system that has obviously clearly inarguably failed.
LC3's non-delivery is just one drastic vast highly-observable fuck up. The failure of 5.0 to arrive in consumer devices for basiclly half a decade rings so profoundly scarily true. There still being noting post 5.0 available so widely confirms these horrible beliefs. Bluetooth miserably fails to make it's way into the world. It's a constant wreck, constantly vastly behind. Specs that are so under-performant dont deserve this endless chance to deliver more.
We're well past the point where there need to be other possibilities. Bluetooth has held the world hostage, has perpetually been lopsided in what it does. In other threads I mentioned how pipewire, finally, is creating a more equitable situation by creating a Hands Free Profile bluetooth device, but only via minimal circumstances, short of all the good & better specs. Bluetooth just fails, can't do, is resistance in the world, giving more fixedness & constraint than benefit today. Bluetooth is sad.
PipeWire 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.
