We can do either or both ourselves without any specification or dedicated API, I have no way to determine if the workarounds that I tested are simple, I do know that they are capable of meeting each requirement above. There are no specifications or API's that include that language or perform that process deliberately and intentionally. To capture specific application output we need to capture playback streams discretely. That provides a means to listen as a neutral observer in Google Meet or other similar application, and capture the output described at this issue.Ĭhrome and Chromium refuse to support that functionality at enumerateDevices() and getUserMedia(). On Firefox when no microphones are connected monitor devices are listed and can be captured. I can't assume that the solution would be this simple, but it's a possibility and this piece of functionality has been missing from Discord (in fact, pretty much every electron app) under Linux for years. Per the relevant specification, getUserMedia() is intended for microphone capture, even though the term of art "audiooutput" is in that specification, only Chrome and Chromium implement that that kind in MediaDeviceInfo object in fulfilled Promise object from enumerateDevices().
#SCREEN SHARING DISCORD SOUND FRAME CAP HOW TO#
Users would just need to know how to select monitor devices without selecting microphone devices and vice versa. If the goal is to capture only all output, if Electron is build using Chromium source code, then yes, reverting that change should provide a means to list and capture monitor devices using getUserMedia(). Users need to be able to also select specific playback streams for capture. On Linux the monitor device will capture all system audio output.
If Discord is internally choking because it's not finding an appropriate monitor device, this should, at least very theoretically, revert the problem? If Discord is internally choking because it's not finding an appropriate monitor device, this should, at least very theoretically, revert the problem? I can't assume that the solution would be this simple, but it's a possibility and this piece of functionality has been missing from Discord (in fact, pretty much every electron app) under Linux for years.Ī more plausible and probably more complex solution would be to build a custom release of Electron with commit reverted and see if that changes anything. (I might be able to figure it out with enough time as well, but I can't really guarantee that right now.)Ī more plausible and probably more complex solution would be to build a custom release of Electron with commit reverted and build a new copy of Lightcord against it. This would be a better question for the Lightcord developers as to whether or not this is even possible to do.
#SCREEN SHARING DISCORD SOUND FRAME CAP CODE#
We would need some way of overriding the default WebRTC code that sets up the desktop stream (if how I'm assuming Lightcord works is correct) in order to plug anything new in. Unfortunately, I'm not familiar enough with Lightcord's codebase to make any particularly sweeping changes to the program. Reverting that change will not break the web or confuse users who transparently decide to capture monitor devices.
What I would first do is build Electron using Chromium source with the change that refuses to list or capture monitor devices reverted. I have been doing this for several years now to no avail, thus I create workarounds. I would suggest that if there is interest in capturing whatever audio devices you want without the browser arbitrarily restricting what you can to star the relevant issues and contribute to the issues, both specification and Chromium bug to affirmatively let the maintainers know this is not a fleeting concern and not just a handful of developers, rather this is a genuine use case that will not just go away - and that we should not have to capture video just to capture system or application specific audio output. Several workarounds are included at, primarily using inotify-tools and File System Access API to perform tasks when a file is accessed.Īs I stated in the Web Audio v2 issue, there is no API to capture system or specific application audio. Pactl can be used (with Native Messaging or WebTransport) to dynamically get, list, and set specific sources and source outputs for capture by changing the microphone initially captured with getUserMedia().
Since Electron is based on Chromium source code, Electron can be built without the change that refuses to list or capture monitor devices on Linux, Eloston/ungoogled-chromium#1273.