Hacker News Reader

Comment by jcelerier | Hacker News Reader

The best software stack for bluetooth audio is the one provided by Pipewire on Linux.

I switched after seeing PRs improving Pulseaudio get shot down pretty dismissively, and iirc the would-be contributor getting fed up, abandoning it because well whatever, Pipewire.

But actually, since switching the AV sync is off using my Bluetooth earphones, at least in Firefox.

Curiously, I can fix it with latency adjustment in pavucontrol, but it only has an affect when the 'advanced' drop down is revealed in that tab of the menu. Close it, and it's off again. Open, and the value has persisted, and it works again. Haven't really dug into that because I've been hoping the (presumably) underlying Pipewire issue will be fixed.

Oof, I saw that PR drama too (~half of bluetooth headsets were broken, PR fixed it, got ignored for months despite loads of 3rd party attention, author got heated, maintainers show up very interested in swinging their CoC around but very uninterested in merging the fix, author gave up and left for pipewire).

Pulse is still broken a year later, pipewire is fixed.

So it goes.

For the curious: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

Pipewire is not written by or maintained by the same people who did PulseAudio. Thus, such experience likely does not carry over.

That is not to say Pipewire could not also be a problem, but I haven't encountered such complaints about it.

Does it handle headsets correctly?

Asking the real questions here.

I finally gave up on using an XPS15 with Ubuntu because I could not get over the fact it cannot do high quality bi-direction bluetooth audio.

Edit: Looks like it does offer some improvments over pulseaudio: https://www.redpill-linpro.com/techblog/2021/05/31/better-bl....

I finally figured out how to get bluetooth headsets to work correctly on my desktop: output to 3.5mm, 3.5mm to dedicated bluetooth transmitter.

Throw hardware at the software problem, because software absolutely cannot be trusted not to foul this up. Not Windows, not linux, not pipewire, not pulse, none of it. Evidently not mac either, though I've personally never had trouble with bluetooth on mac. Bluetooth is 23 years old and its flagship application is still completely broken across huge swaths of the client/server compatibility matrix.

Pipewire for some reason insists on using GTK4 for its UI though, which hangs X cold if you use any of the popovers in it. I didn't even know it was possible to hang X like that.

Is that an X issue or a GTK issue? Haven't heard of this before and it sounds scary

What do you mean by a Pipewire UI? It's a background daemon (or three: pipewire, a session manager, and pipewire-pulse).

EDIT: Perhaps the parent means Helvum, which ldd says links to libgtk-4.so.1 => /usr/lib/libgtk-4.so.1. However, I can't figure out how to open a popover (https://python-gtk-3-tutorial.readthedocs.io/en/latest/popov...) in the app; all I can do is drag to create or break connections.

Try to set up https://github.com/jaakkopasanen/AutoEq impulse responses for headphones, and you _will_ inevitably hang your X. Daemon isn't terribly useful on its own if you can't set it up to do what you need. So anyone considering Pipewire as a "better" alternative to anything should also know, at a minimum, that it's difficult/impossible to uninstall and buggy AF.

To clarify things, PipeWire is an audio daemon, completely unaffiliated with https://github.com/jaakkopasanen/AutoEq which is a set of headphone impulse responses. It just so happens that the recommended way to apply these impulse responses on Linux is EasyEffects, which now depends on both PipeWire and GTK4. Nonetheless, PipeWire is not EasyEffects and not AutoEq, and "Pipewire for some reason insists on using GTK4 for its UI though" is untrue because EasyEffects is not PipeWire's official GUI, and doesn't even come up when I search `pipewire gui`.

I haven't tested EasyEffects. With that in mind, PipeWire is buggy AF for the time being, and I've been working over the past week to clean things up (fixed a few bugs in plasmashell and pipewire so far, but I'm still learning and there's a great deal of bugs I haven't diagnosed and explained to the maintainers, it will probably take weeks longer for me to work through everything, and I'd very much prefer the program was written to handle race conditions and edge cases properly, instead of leaving users to discover bugs and trace the root cause through the labyrinthine IPC-heavy event-driven codebase after the fact).

Their choice to write new code in C at this late date is hard to justify. A bit of abstraction and automation can go a long way.

My guess is that Pipewire is written in C because the author likes C (or at least somewhat dislikes C++). And it has "abstraction"... in the form of hand-baked vtables and observers created out of nested macros, void*, and intrusive linked lists.

An advantage of C is that it comes with a stable ABI, where Rust is unstable and C++ is a subject of conflict (though you can achieve a stable ABI by restricting your external API to C functions, and if you want cross-shared-object virtual calls like Pipewire, you might have to write the same pile of macros as PipeWire, which you were trying to save yourself from). The downsides are memory and type unsafety (surprisingly the only crash I've seen so far is a null pointer dereference, and I haven't hit any obvious memory or type errors), and a complete absence of "vocabulary" or templated types (they've created their own slotmap-like ID allocator but without a generation count resulting in ever-present "logical use-after-frees" in library and application code, and an intrusive linked list which they use even when hashmaps might provide somewhat faster iteration and asymptotically faster search).

I assumed the C ABI, and thus the cobbled-up vtables. Where the author might have used C++ to advantage would be automating other, internal details of the code. There is nothing quite like bugs you don't have because you didn't need to write the code where they would have been, or because you could run code at compile time to generate or at least verify your cobbled-together apparatus.

The saving grace is that it can at any time be switched over to be built with a C++ compiler, and then start to be modernized incrementally.

What you say is true. Unfortunately I don't think you can trivially switch it to a C++ compiler, because they use {[FOO] = ...} initialization.

It would be cool (not necessarily useful, probably not a good use of time) to rewrite it in Rust while keeping the dependency count in the single digits. It would be helpful to contributors to add architectural documentation.

Clang supports it in C++ mode but not GCC sadly :(

C++ has a version of that notation, with minor (and IMHO unnecesssary) restrictions that probably impose no hardship.

C++20 added dot initialization, which has been supported in MSVC/GCC/Clang for over a year now. No released version of the C++ standard supports array index initialization, and jcelerier says Clang but not GCC supports it as an extension.

I use qjackctl as "pipewire UI", works fine

Reply on news.ycombinator.com