> drawing the situation so badly is unreasonable IMO. But I'm not sure I would be happy with my streams switching on their own discretion. I think pulse can be patched to switch existing streams to newly added cards. It can be really useful especially for people using external sound cards and plugging-in them late (e.g. So it seems to be working at least on linux.Īgain, I'm not against adding such features. Wrt WebRTC, there is a service called Bluejeans that I use via Firefox 51 WebRTC implementation. Is it possible to switch output per app in windows 10? I will not talk about windows though as I don't personally use it.
Last time I looked at some windows machine, it seemed to control audio streams per application in an audio server like approach. Yes, this is not dynamic but is an option for people that want to resist pulse (and I haven't had any issues with pulse (unlike during early introduction) for years. So newly opened streams ended up on the plugged-in card. I've been personally resisting pulse for years and I've been able to redirect FF audio output using environment variables:Īlso if a USB card is plugged, at least on my distro (fedora but IIRC debian also that I used in the past) it became the default. I can switch outputs dynamically using pulse mixer. I am using ff 51 ATM and I see a separate stream in pulse mixer for each youtube video I start playing. I believe any version of firefox (and any other application) does create a new stream in pulse. We're going to have to unlist Firefox as a supported browser now, as much as I hate to impose browser constraints on to our customers.ĥ years I am not against adding more functionality to Firefox but drawing the situation so badly is unreasonable IMO. I'm shocked that you still don't have it. The lack of any capability to ensure that one's audio output device is synchronized to their input device is why our organization didn't release WebRTC support for Firefox two years ago. Now you just need to support them properly.) It should have been implemented before considering NPAPI to be useless (per your dev team's blog posts about NPAPI, yes, everything is replaced with w3c spec'd APIs.
Looking at their github, they seem focused on audio input, not output. Maybe whoever chose to use libcubeb for audio output made the wrong decision, or a decision that was only good for the time. I understand that this is going to require pretty much a rewrite based on above comments about using a third party library (libcubeb) that doesn't support the required functionality. Considering Java is about to be disabled, audiooutput "kind" in enumerateDevices, as well as everything needed to pipe received WebRTC audio through to any chosen audiooutput device should get bumped up in priority.
0 kommentar(er)
