1315149 - WebRTC - Media Stream Error When Tracks Not Closed Before New GetUserMedia

Status: RESOLVED DUPLICATE of bug 1238038

(Core :: WebRTC: Audio/Video, defect)

Description

[Maxime Marchand]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.87 Safari/537.36

Steps to reproduce:

After the initial navigator.mediaDevices.getUserMedia(constraints), the tracks need to be closed before calling getUserMedia again (with a specific deviceId), else an error is caught:

 MediaStreamError { name: "SourceUnavailableError", message: "Failed to allocate audiosource", constraint: "", stack: "" }

Steps to reproduce:

1) Use constraints with some device, ex:

 var constraints = {
    audio: {deviceId: {exact: device}},
    video: false
  };

2) navigator.mediaDevices.getUserMedia(constraints)

3) On success, set Sender ex:  

stream.getTracks().forEach(track => {
    sender = pc.addTrack(track, stream);
 });

4) Get a new userMedia with a new device2

navigator.mediaDevices.getUserMedia(constraints) where constraints has device2

Note: the deviceID for device and device2 come from navigator.mediaDevices.enumerateDevices()


Actual results:

I get the following error:

 MediaStreamError { name: "SourceUnavailableError", message: "Failed to allocate audiosource", constraint: "", stack: "" }

If I close the tracks before the second getUserMedia, no error is thrown. That said, by stopping the track before getUserMedia, the media is stopped until the user accepts the new device in the accept prompt - which is not smooth at all if happening in an ongoing call.


Expected results:

I believe this should not throw an error (it does not on Chrome and Opera - not using the Track API).

If required, I can add a test client which reproduces the error...

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

That's due to full_duplex input not allowing multiple active inputs at the same time at the moment.  Bug 1238038

Full_duplex is still off in release (and 50 beta); it's hoped to be enabled in 51.  A full solution for bug 1238038 is unlikely to be 51, but we might be able to implement something hackier, such as when a new mic is selected and opens, switching all active inputs to the new mic (but if older tracks have .stop() called, it would not stop other active inputs of course).

Comment 2

[Maxime Marchand]

@Randell

Thank you very much for that information.

The use case behind this bug is "microphone or camera change" during an ongoing call with a smooth transition. Until a fix or hack is performed, media is stopped until the user accepts the new device - which creates an unwanted pause during the call when a user changes device.