I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
- I don’t have to use Chromium for my mic to work on online video conf (WTF Firefox)
- “EasyEffects” lets me quickly fix crappy youtube audio (bad gain normalisation, way too much sibilance) with a minimum of effort.
Cons:
- Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
- First time setup is complicated, involving environment variables, dbus user session buses and multiple daemons (running just pipewire isn’t enough). Why can’t it handle this all itself? Surely it should notice if these things are missing and just fix it itself? Compare this to straight ALSA where you (1) do nothing and then (2) everything works (except Firefox mic support)
- I can’t have multiple audio outputs all unmuted at the same time. Eg my headphone output and my rear speaker output. If I override this (using alsamixer) then it gets forgotten next boot anyway, it seems to be out of scope of PipeWire’s understanding.
Oh nice! I wonder if this will fix discord streaming audio?
Can you describe the issue? I don’t use Discord (and I presume the problem might depend on what browser you use).
I’m assuming this is a “dedicated app” (i.e. apt install discord). I was capable of streaming the video, but sound was a different beast. Audio streaming on discord was a no go. I was finally able to do it with pipewire and using discord-screenaudio
https://github.com/maltejur/discord-screenaudio
A custom discord client that supports streaming with audio on Linux
Jaysus, I wish this were a world where stuff like that wasn’t necessary.
Uneducated question: what’s the benefit of a dedicated client over running it in a normal browser?
Sorry for late reply. I just now noticed this.
The difference would be that a browser would likely have multiple web pages fighting for resources whereas the dedicated client would not have to fight over so many resources.
The OS has a dedicated task scheduler that alots cpu time to each process. Some processes get preferential treatment, but most processes started on user space ( i.e.double click UI icon) are just “normal” priority.
When a task scheduler hits on a process, that process can start executing whatever it needs to do. The problem with running discord in a browser is that the application is splitting its attention across multiple pages ( and probably other stuff ) instead of a single page.
Basically, it’s faster to focus on painting a single canvas than it is to painting 3 at the same time.
I’m not going to discuss shared memory and separate processes or forking. You can goggle search if you want to know more about that.
I am not so sure that it will end up faster or better.
**In theory: **A CPU scheduler should give programs as much CPU time as they want until you start nearing CPU resource saturation. Discord doesn’t need very large amounts of CPU (admittedly it’s a lot more than it should for a text chap app, but it’s still not diabolically bad). It will only start getting starved when you are highly utilising all cores. That can happen on my 2-core laptop, but I don’t have any games on my 6 core desktop that will eat everything. Nonetheless on my laptop I’d probably prefer my games take the resources (not Discord) and I’d happily suffer any reasonable drop in responsiveness of Discord as a result.
I don’t think that a new process (a new dedicated browser-client) instead of a new thread (tab in existing browser) is intrinsically faster or better. CPU schedulers are varied and complex, I wouldn’t be surprised if any differences in performance measurements would end up down in the noise. If anything the extra memory usage might cause more IO contention and memory starvation, making everything slower rather than faster. But this is all conjecture, so don’t give it much credit.
Basically, it’s faster to focus on painting a single canvas than it is to painting 3 at the same time.
I don’t think that’s much of a problem in practice, at least for Firefox: one tab can crash and stop rendering completely (or lock up 100% of 1 CPU core) but the others will keep going in other threads. For the most part they shouldn’t be able to affect each other’s performance.
In practice: What’s the actual metric that you think will be better or worse? I assume responsiveness to typing and clicks in the discord UI?
I’ve never seen discord lag or stutter from causes other than IO limitations (startup speed, network traffic, heavy IO on my machine) or silly design (having to refresh the page after leaving it open all day, I suspect it’s intentionally auto-disabling but I’m not sure). That’s not something that running a separate discord client in a separate dedicated/embedded browser will fix.
lets go
