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 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.
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.
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 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.
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.
deleted by creator