3 ms·
Try to set up https://github.com/jaakkopasanen/AutoEq https://github.com/jaakkopasanen/AutoEq impulse responses for headphones, and you _will_ inevitably hang y
by m0zg 5y ago
Try to set up https://github.com/jaakkopasanen/AutoEq 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.
- nyanpasu64 5y agoTo clarify things, PipeWire is an audio daemon, completely unaffiliated with https://github.com/jaakkopasanen/AutoEq 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).
- ncmncm 5y agoTheir 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.
- nyanpasu64 5y agoMy 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).
- ncmncm 5y agoI 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.
- nyanpasu64 5y agoWhat 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.
- jcelerier 5y agoClang supports it in C++ mode but not GCC sadly :(
- ncmncm 5y agoC++ has a version of that notation, with minor (and IMHO unnecesssary) restrictions that probably impose no hardship.
- nyanpasu64 5y agoC++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.