[Linux] Give the microphone input and the stream audio input streams unique names

[Vinjul1704]

Description

Since both audio input streams use the same (default?) name, "Chromium input", I am having issues getting the selected input sources to stick, even without restarting the program, causing issues like my microphone suddenly being used for stream audio and the game audio being used as the microphone.

As-is, it is also not possible to easily figure out which input stream is which in tools like pavucontrol without actually testing it. Since they share the same name, they also seem to use the same config entry, possibly leading to the wrong input source being saved between restarts.

Suggestions

Giving both audio input streams unique names, such as "WebCord Mic Input" and "WebCord Stream Input", should prevent this. It will also make it easy to figure out which is which at a glance.

Alternatives

No response

Additional Context

This is only relevant when running WebCord on Linux and using the -force-audio-share-support argument.

[SpacingBat3]

Well, it is Chromium engine that manages it, Electron does not expose any APIs to create or manage audio streams used for both input and output AFAIK (they barely expose libnotify on Linux lol, for instance you still can't assign your own buttons to the notification). So I guess this one feat request is very unlikely to be implemented in the future.

[Vinjul1704]

Well, it is Chromium engine that manages it, Electron does not expose any APIs to create or manage audio streams used for both input and output AFAIK (they barely expose libnotify on Linux lol, for instance you still can't assign your own buttons to the notification). So I guess this one feat request is very unlikely to be implemented in the future.

Hmm, what would be a good place to request this at then? The electron repo?

[SpacingBat3]

Possibly, I guess Electron doesn't even have to leak any kind of the APIs to implement this, they just need to handle renaming the streams. But given --force-audio-share-support is more of a workaround and both Electron and Chromium didn't seem to care about implementing the proper screen-with-audio sharing support (in fact, Electron team calls this an upstream issue and in Chromium bug tracker this is a low-priority issue), it feels like no one might consider working on this (I feel like the --force-audio-share-support itself works only because Electron team didn't remove the ability to try using audio sharing within Chromium engine on platforms it doesn't support doing that).

I should also say audio sharing is usually not supported by the browser engines at all due they don't have to implement it in order to comply with the WebRTC or any other spec (meaning it feels there's no pressure at implementing it at all), or at least that's what I believe to heard of it once somewhere when doing some research about this issue.

[Vinjul1704]

Possibly, I guess Electron doesn't even have to leak any kind of the APIs to implement this, they just need to handle renaming the streams. But given --force-audio-share-support is more of a workaround and both Electron and Chromium didn't seem to care about implementing the proper screen-with-audio sharing support (in fact, Electron team calls this an upstream issue and in Chromium bug tracker this is a low-priority issue), it feels like no one might consider working on this (I feel like the --force-audio-share-support itself works only because Electron team didn't remove the ability to try using audio sharing within Chromium engine on platforms it doesn't support doing that).

I should also say audio sharing is usually not supported by the browser engines at all due they don't have to implement it in order to comply with the WebRTC or any other spec (meaning it feels there's no pressure at implementing it at all), or at least that's what I believe to heard of it once somewhere when doing some research about this issue.

Thanks, I will try to make a report there then. I feel like being able to change the names of audio streams is a useful enough feature on its own, unrelated to this specific use case.

[SpacingBat3]

Also a bit related (yet not around implementing exactly what you mention/want) issue in Electron bug tracker: electron/electron#27581.

[SpacingBat3]

@Vinjul1704 Try out Electron 29 (currently at beta) and WebCord 4.7.0, I'm not 100% sure but I think that given audio sharing is now properly implemented for Linux there, you might get different stream names (I think Chromium Capture is now displayed for screen sharing).

[Vinjul1704]

@Vinjul1704 Try out Electron 29 (currently at beta) and WebCord 4.7.0, I'm not 100% sure but I think that given audio sharing is now properly implemented for Linux there, you might get different stream names (I think Chromium Capture is now displayed for screen sharing).

Thanks for the heads up. Looks like using the latest 29 beta (4) doesn't change anything for me yet, but hopefully that will change with the stable release.