I’ve hacked around this using Pipewire. I used qJackCtl to route the audio output of my game into Discord’s audio input. Suboptimal, because people will hear my audio regardless of whether they joined the video stream or not, but not it worked for the scenarios I needed it to work for.
Discord will need to fix their code on Linux if they want to support this stuff out of the box. Pipewire supports streaming application audio just fine, but that doesn’t matter if Discord doesn’t implement it.
Kind of the same deal with Zoom and video sharing on Linux: they decided to use the wrong API (screenshot API) so there’s no way for the rest of the platform to fix their limitations.
on discord on linux you can’t screenshare with desktop audio, I think this might be already fixed in newer electron versions (but discord is closed source and has not updated their electron in a long time)
As a workaround, you could use OBS and use OBS’s virtual camera so Discord is streaming what it thinks is a camera, and set up whatever you want to share on your desktop through OBS.
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
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.
I have discord installed from the flatpak. Screen sharing works but it doesn’t share audio from the applications. Discord-screenaudio and web browser discord have been suggested to me but they don’t work with unfocused push to talk. I’ve also tried xwaylandvideobridge but that didn’t stream the audio either.
Discord doesn’t support steaming desktop audio when screen sharing on Linux. They do on other platforms and there’s no technical reason why they do t support it, they just don’t seem to care all that much.
Oh nice! I wonder if this will fix discord streaming audio?
Nope. This will only be fixed when Discord gets their head out of their ass, unlikely to happen soon.
I’ve hacked around this using Pipewire. I used qJackCtl to route the audio output of my game into Discord’s audio input. Suboptimal, because people will hear my audio regardless of whether they joined the video stream or not, but not it worked for the scenarios I needed it to work for.
Discord will need to fix their code on Linux if they want to support this stuff out of the box. Pipewire supports streaming application audio just fine, but that doesn’t matter if Discord doesn’t implement it.
Kind of the same deal with Zoom and video sharing on Linux: they decided to use the wrong API (screenshot API) so there’s no way for the rest of the platform to fix their limitations.
Can you describe the issue? I don’t use Discord (and I presume the problem might depend on what browser you use).
on discord on linux you can’t screenshare with desktop audio, I think this might be already fixed in newer electron versions (but discord is closed source and has not updated their electron in a long time)
That absolutely sucks :| Thankyou for the detail.
As a workaround, you could use OBS and use OBS’s virtual camera so Discord is streaming what it thinks is a camera, and set up whatever you want to share on your desktop through OBS.
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
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.
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.
I have discord installed from the flatpak. Screen sharing works but it doesn’t share audio from the applications. Discord-screenaudio and web browser discord have been suggested to me but they don’t work with unfocused push to talk. I’ve also tried xwaylandvideobridge but that didn’t stream the audio either.
Discord doesn’t support steaming desktop audio when screen sharing on Linux. They do on other platforms and there’s no technical reason why they do t support it, they just don’t seem to care all that much.