1439568 - Unplugging the USB headset device during a call freezes the call

Status: NEW

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

Description

[ovidiu boca[:Ovidiu]]

Affected versions]:

Tested on Beta 59.b11

[Affected platforms]:

Tested on Windows 10. 

[Steps to reproduce]:

Prerequisites:

 A working headset is required to run this test case. The term headset refers to a device that has headphones and a microphone.
We used USB headset. 
You need to have 2 computers - one of them needs to have Windows 10. 

 STR:

1. Start a call on a random WebRTC service (https://appr.tc/)
2. From the other computer join the same call. 
3. Plug the headset into the machine and check audio/video.
4. Plug the USB headset into the Windows 10 machine and check audio/video.
5. Unplug the headset from the computer used in step 3 and check audio/video.
6. Unplug the headset from the Windows 10 machine and check audio/video.

[Expected result]:

The call doesn't freeze. 

[Actual result]:

The call freezes. 


NOTE: This issue is not reproducible on Nightly 60, we tried to find a regression fix for this but we weren't able.
This issue is also reproducible on FF 58 release. 
Please see also bug 1426333, maybe they are related.

Comment 1

[Andreas Pehrson [:pehrsons]]

If this doesn't affect nightly we can't really take any action without a regression range (well, fix range in this case really). Are you saying that it doesn't repro on an old (59) nightly? Or is it intermittent?

Comment 2

[Alex Chronopoulos [:achronop]]

I give a lower priority since it's not reproducible in Nightly.

Comment 3

[ovidiu boca[:Ovidiu]]

We also tested FF Nightly 59.0a1(2018-01-03) and we can reproduce this. We tried with mozregression but unfortunately, when we try to start a call on a build downloaded by mozregression we don't have video recording and we are not able to see when the image freezes or not.

Comment 4

[Andreas Pehrson [:pehrsons]]

Is another app using the camera when you can't get video capture to work?

Can you do it audio-only instead and test the freezing against the current time of the audio element? Like on https://mozilla.github.io/webrtc-landing/gum_test.html

Comment 5

[ovidiu boca[:Ovidiu]]

We don't use any other app.
We did test this using only audio. 
Here is the scenario:

1. Plugged in USB headset and started the audio capture - (everything works) 
2. Unplug the USB headset - you can't hear anything but the call is not stopped (the counter from the test page is not stopped)
3. Plugged in USB headset - you can't hear anything

Comment 6

[Andreas Pehrson [:pehrsons]]

This might just be bug 1439943, with video working in Nightly thanks to bug 1408294.

Comment 7

[Camelia Badau [:cbadau], Desktop Test Engineering]

We managed to reproduce this bug on:
- https://opentokrtc.com/ making a call between Windows 10 (Firefox 59 Beta 12) and Ubuntu 16.04 (latest Nightly) - freeze after B (Ubuntu 16.04) unplugs/plugs and then A(Windows 10) plugs/unplugs
- https://web.ciscospark.com./ making a call between Windows 7 (Cisco Spark Native Client) and Windows 10 (Firefox 59 Beta 12, Cisco Spark Web app) - when you unplug the headset, the call freezes. 
- https://apprtc.appspot.com/, making a call between Ubuntu 16.04 (Chrome Release) and Windows 7 (Firefox 59  Beta 12) - when you unplug the headset, the call freezes.

Comment 8

[Andreas Pehrson [:pehrsons]]

It is unclear to me what the bug here is.

In the STR, step 1 seems to assume there is already a microphone present (so the call can start), is this correct?
Which microphone do you select in the permission prompt?


"The call freezes" is ambiguous:
Does the remote video track freeze (freeze meaning we're stuck with an old image) for either machine?
Does the self-view video track freeze on either machine?
Does audio capture stop (per the address bar icon) when you unplug on either machine?
Does audio output stop on either machine (that is, output of MediaStreams on the same page, easiest way to check is probably to unmute the self view, though that could be tricky).
And for any "either machine" above, which machine was it? This could be in the audio backend and the implementations are different for all platforms.


Also, on a hunch, after this has gone frozen; if you load https://mozilla.github.io/webrtc-landing/gum_test.html in the same window, does audio + video work?

Comment 9

[ovidiu boca[:Ovidiu]]

I retested this on Windows 10 x64 with FF beta 59.0b12 and I used the same steps as in the description and after I did the last step I have this results: 

On my machine where I used Windows 10 the video and audio are frizzed, the video is stuck with my last capture image and also the image with the callee is stuck on my monitor. The sound capture is stopped. 

On the callee computer, the sound is working, he can hear only himself. The video capture from his camera is working only the capture from the caller is blocked on his screen. 
The call was made between Windows 10 x64 - caller and Windows 10 x64 - callee

If I load the https://mozilla.github.io/webrtc-landing/gum_test.html in the same window the video capture is working but the sound is not captured by the headphones microphone it uses the build in laptop microphone, please note that the headsets were plugged in before I load https://mozilla.github.io/webrtc-landing/gum_test.html

Comment 10

[Timea Cernea [:tbabos][inactive]]

Further testing revealed that during a call on the latest Nightly 63.0a1 (2018-08-12) (64-bit) on Ubuntu 16.04. and Mac 10.12 systems, the video froze for both the calle and caller when the TRRS Jack was unplugged.

Should we submit a new bug for the above mentioned issue?

Comment 11

[Paul Adenot (:padenot)]

I still can't repro this, fwiw, I just re-tested on my macbook.

Comment 12

[Timea Cernea [:tbabos][inactive]]

We reproduced the issue by unplugging the TRRS Jack as mentioned in Comment 10 during the call between a miniMac 10.12 and HP Laptop with Ubuntu 16.04 OS.

Comment 13

[Paul Adenot (:padenot)]

Right. This means there was no sound card left.

Comment 14

[Timea Cernea [:tbabos][inactive]]

We didn't manage to reproduce it anymore during the call between the same HP Laptop with Ubuntu 16.04 OS and a macBook Pro with Mac 10.12 by following the same steps as described in Comment 10. Seems to be reproducible only on a miniMac.

Comment 15

[Andreas Pehrson [:pehrsons]]

It's unclear to me whether this mac issue is the same as the windows issue in comment 9. If you have also tested windows and see the same symptoms we could keep it in this bug, but if symptoms differ please file a new bug.

Comment 16

[Timea Cernea [:tbabos][inactive]]

Retested with the same setup as in Comment 10. The video only froze once for 2-3 second and resumes afterward, thus we couldn't reproduce the long-lasting freeze as it seems to be an intermittent issue. 
To sum it up, unplugging the TRRS Jack may cause the same symptoms (encountered only on miniMac) as on Windows (unplugging USB Headset).

Comment 17

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

This issue is still reproducible.

Comment 18

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

We encountered this issue using the https://web.ciscospark.com./ service. It occured on Fx 66.0a1, Fx 65.0b10 and Fx 64.0.2 while unplugging the USB headphones.

Comment 19

[Alex Chronopoulos [:achronop]]

Cristian, do you have it on other WebRTC services like appear.in or the gum test page [1] ?
Also, what platform are you testing?

[1] https://mozilla.github.io/webrtc-landing/gum_test.html

Comment 20

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

Hello Alex!
We tried the gum test page and appear.in, however we did not encounter the issue.