When the 'Story Teller' leaves a botc.app game inside Vingester, audio redirects to system default.

[ryantheleach]

I haven't delved deep enough to work out the details yet, but Botc.app implements a voice chat over WebRTC.

When the head of the game leaves and rejoins, Vingester starts outputting audio to the system default device, instead of the configured devices for each browser.

I suspect that Vingester may be polling for changes too slow, to redirect the output.

This issue is specifically with the version posted by @steveseguin here: https://github.com/rse/vingester/pull/80

[steveseguin]

@ryantheleach Did the change I offer make things worse or better?

If I recall, vingester has a mutation observer set up on the body element, and changes to elements will trigger a configuration setup. This setup includes setting the setSinkId value, which sets the output audio device target.

If your RTC application makes changes to the audio element that either:

• changes the setSinkId value
• changes the media stream of that audio/video element then it might be possible no event triggers the mutation observer, so no re-configuration runs.

It might be also possible the configuration only runs once at all, despite a secondary mutation event.

My suggestion to address this might be to add code that listens for loadedmetadata and playing events, and re-run the logic on the video/audio events in this case. It would also make sense to have an interval timer run on top of this, just in case that doesn't work.

I can technically can make this change myself, and release a new build on my github, but I'll give Ralf a chance to respond first and to get confirmation from you.

[ryantheleach]

Hey Steve, I've been battling this issue since I first bought it up, and have been trying to work out exactly what the application is doing, but as it's not one that's actively under my control, it's a little awkward.

I'd really appreciate it if you could make those changes, I'd been attempting to create my own interval timer to fix other disconnection/reconnection issues, but there's still something that is making it switch to the default device.

and as it's generally a longish recording session, it's been a little difficult to debug and run the game simultaneously.

Understand if you don't have the time however, and I could attempt to fork it or something.

Ideally I wish that there was a more reliable way to hook the output devices, like, preferably from outside the chromium instance, but understand that might not be easy, or feasible.

The other option would be to write some custom JS for this specific application, so I could set the output device used directly, but I suspect the developer would more likely prioritize other features first, and that it may be difficult to come up with a hook, considering it uses vue and minified javascript.

[ryantheleach]

Other options I've considered, (to varying degrees)

1. Running some other alternate electron capture utility

• cons:
  • Vingester is useful, because is has a single control interface for managing multiple windows. (nice to have)
  • Vingester is able to inject custom CSS and JS (needed)

2. Using OBS audio app capture beta

• Does not work with Vingester, due to technicalities with how the windows audio stack works, and that OBS doesn't differentiate between the child processes

3. Using NDI

• Haven't yet investigated, but afaik this application doesn't work particularly well in headless, it seems to need user-interaction in order to load/reload, but that may be bypassable.
• Adds additional complications, but may be a working method, but the github issue tracker for NDI issues doesn't inspire hope.

4. Running multiple VM's or physical hardware (ick)
5. Using Chrome profiles

• I was doing this initially, but I can't remember why I went away from it, never had it work productively, but may not have investigated enough into changing the output device on chrome.

[steveseguin]

I'd really appreciate it if you could make those changes, I'd been attempting to create my own interval timer to fix other disconnection/reconnection issues, but there's still something that is making it switch to the default device.

The idea would be to do just mass spam endless the audio output:

setInterval(function(){
  document.querySelectorAll("audio,video").forEach(media=>{media.setSinkId = "deviceID";})
},1000);

If the page contains iframes / shadowroots, you may need to handle them specifically also, as querySelector might not find them.

You've created a ticket on Electron Capture, https://github.com/steveseguin/electroncapture/issues/104#issuecomment-2677562712, and I can add JSS injection for you if you need it, as there is already CSS injection.