SpacingBat3
Streaming audio from all programs, even if not selected
Aknowledgements
-
[X] I have checked that there's no other issue describing the same or similar problem that I currently have, regardless if it has been closed or open.
-
[X] I can confirm that this is not an issue with the Discord website, but it is a problem specific to the WebCord itself. I have tested if this bug occurs on Chromium/Chrome or any other Chromium-based browser that uses unpatched/upstream Chromium engine.
-
[ ] I have tried running the build from the
masterbranch and it does not have any fixes implemented according to my issue. -
[ ] My issue describes one of the unstable and/or not fully implemented features.
-
[ ] I have found a workaround to mitigate or temporarily fix this issue in affected releases (please write it in Additional context section below).
Operating System / Platform
🪟️ Windows
Operating system architecture
x64 (64-bit Intel/AMD)
Electron version
19.0.8
Application version
3.5.0
Bug description
While streaming, you stream the Audio of all programs, not just the one you selected.
When streaming your whole Monitor/Desktop, you also stream all Audio, Discord normally doesn't stream any at all. It would be nice to have a selector if you want to stream with or without Audio, everybody would just hear themselves xd
Additional context
No response
While streaming, you stream the Audio of all programs, not just the one you selected.
This is actually the expected behavior. There's no way to pick in the Electron a window as an audio input AFAIK. This wasn't the case at least on Linux and Electron docs doesn't mention it at all. So this is unlikely to be fixed.
When streaming your whole Monitor/Desktop, you also stream all Audio, Discord normally doesn't stream any at all.
On WebCord, it's up to you whenever you want to record an audio or not. There's a button/checkbox to select whenever you want to share an audio or not, so it's implemented. By the default, it should be disabled.
On WebCord, it's up to you whenever you want to record an audio or not. There's a button/checkbox to select whenever you want to share an audio or not, so it's implemented. By the default, it should be disabled.
Yeah, thanks, actually didn't notice that it ^^
While streaming, you stream the Audio of all programs, not just the one you selected.
This is actually the expected behavior. There's no way to pick in the Electron a window as an audio input AFAIK. This wasn't the case at least on Linux and Electron docs doesn't mention it at all. So this is unlikely to be fixed.
This is actually bad and would really suck. I, as probably many others, am trying to use WebCord as daily driver, but this would completely break it for me personally. It is an essential feature of Discord streams, and everyone just hearing each other really isn't a good experience. Especially in comparison that Discord has that working since years (and is also using the Electron framework).
Especially in comparison that Discord has that working since years (and is also using the Electron framework).
Electron uses a native module to re-implement a WebRTC. On contrast, WebCord uses a WebRTC implemented within Chromium and if Chromium is not capable of capturing audio of the single window, there's no easy fix for the audio capture. It would likely needed to be fixed the similar way as #154. As I'm less familiar with Windows through, I wouldn't expect this will be worked on before #154. But since WebCord is open for contributions, anyone can improve it.
I, as probably many others, am trying to use WebCord as daily driver (...)
Using WebCord is still not the experience I would like of it to be, but it's getting drastically better each day. This is why it is not called as a feature-complete client and is expected to be drastically improved over time. And while a lot of things can't be directly fixed or implemented by me, at least now, either due to Electron limitations or lack of time, I still work on stuff like re-implementing an entire cross-process communication within Discord using WebSocket and IPC, and it's getting on the right direction. I might even consider working on RPC some day, leaving it disabled by the default by allowing others to enable it for their own responsibility.
everybody would just hear themselves xd
Also, I've seen that there was some work done on recording a single webContents and that could be used to actually filter the WebCord's window audio from the system audio stream in order to fix this issue. But still, that would be rather complex (mostly because I still don't know how to invert audio in JS/DOM) and it doesn't seem to be implemented on the Electron side as of the current stable release.
Has there been any update to this? Personally, WebCord not being able to only capture audio from a certain windows isn't a huge deal. But when screen sharing with audio, the issue of WebCord also capturing the audio coming from WebCord means anyone else in the call hears an echo of themselves, which is a pretty big issue.
I don't really understand electron, but from what was discussed here it seems like there's a way to at least remove the echo. https://github.com/electron/electron/issues/27337
@JadeTank I really appreciated your comment, but unfortunately it seems that one of Electron team member find this as an upstream issue and preffered to wait for Chromium to resolve it rather than do a patch in Chromium on their own. However, I see someone explained that in case of the Chromium they might not intend to work on it as Chromium uses getDisplayMedia, not getUserMedia with custom constrains as in case of the Electron, so we basically have to wait for the Electron's opinion. I could still prepare my code and add that constrain to make my app ready for it, but I think it is better to hear from Electron team first what they think about it.
I'm honestly unsure if the upstream issue is fixed and loopbackWithMute is actually enough to screen share without app's audio (the name feels like it suggests that, but again I had negative results when screen sharing on Linux with Electron 29, could some Windows user that actively streams via Discord test it?)
TBH, given I'm not the only one asking for loopbackWithMute vs loopback in the API and also because of the lack of the entry in the documentation about it, I feel like even some devs might have no clue what it does. Again loopbackWithMute is the only thing that might work there, there's just no other thing in Electron API that I think that would be implemented to work with that, and Electron developers have seem to closed the upstream issue. I guess if it's still the case, there might be a need to open a new thread in the bug tracker for Electron devs to track this issue.