1078758 - Changing input source midstream causes webrtc to freeze

Status: NEW

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

Description

[Marc Schifer [mschifer]]

Unplugging a USB headset while in call causes the call to freeze.

OS X 10.8.5

STR:
With Headset plugged in. Start a Hello/Loop call.
Once call is in progress - unplug the headset.
Expected: 
  call to continue using native input devices.
Actual:
  Audio/Video freezes, must close session and restart call.


USB Headset in use Generic -  
Mac System reports as 'USB Ear-microphone'
Linux lsub identifies as 'ID 05e1:202a Syntek Semiconductor Co., Ltd'

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

[Tracking Requested - why for this release]:
Just to add this happens with an Aurora build. Not sure if that qualifies for blocking but it is kinda interrupting.

Comment 2

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

Currently this is expected - we can't switch audio devices in mid-call.  See also bug 827146 (hotplug while the permission doorhanger is up).  We've added some support for noticing output devices changing on Mac to change audio panning (for AEC), so on mac at least that can help be part of the solution, but there would be a bunch to do at a low level to support this.  (Plus there's a question of "what to select if they unplug", though perhaps that can be "whatever would be the new default from the OS")

Perhaps as an intermediate step we could notice and force the doorhanger open again.

Comment 3

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

Removing tracking.  This is a well-known limitation of our getUserMedia, and considerable code (and privacy review) would be required to resolve it.

Comment 4

[u279076]

I'd be interesting in knowing how our competition behaves in this situation. Can someone please test Chrome and Opera?

Comment 5

[Nils Ohlmeier [:drno]]

I tested Chrome and it pretty much behaves the same as FF.
Once an audio stream got acquired from the internal mic pluging in a USB headset does not do any thing. You can navigate to their device selection (behind the camera icon), but if you change the audio input device Chrome tells you that you have to reload the page to make that change effective (which basically terminates your audio stream/call).
And disconnecting an USB headset which is currently in use terminates the audio stream, similar to FF. Re-plugin the same headset does not recover the audio stream, same with FF.

Comment 6

[u279076]

Thanks Nils.

Given this behaves similar in Chrome and Firefox, I don't think we should block Hello on this issue. However, I would propose that we do some user education; some combination of release notes, support documentation, or UI warning users when they unplug their devices.

Comment 7

[Nils Ohlmeier [:drno]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #6)
> Given this behaves similar in Chrome and Firefox, I don't think we should
> block Hello on this issue. However, I would propose that we do some user
> education; some combination of release notes, support documentation, or UI
> warning users when they unplug their devices.

Agreed.

Although what makes this pretty miserable is that once you dis-connected your audio device you have reached a lost state from which you can't recover, unless you start a new call. So theoretically we would have to show users a big warning before or during the call "Unplugging a currently used Audio or Video device will leave your call unusable!".

But I agree that showing a UI warning after a user unplugged a device would still help to explain the user what went wrong and how to prevent this in the future.

Comment 8

[ushunmugan]

What is the proper WebRTC way to detect an audio device unplugged?

Comment 9

[Mark Banner (:standard8)]

I believe this still applies to WebRTC. So dropping Hello from the title as that's discontinued now.

Comment 10

[Nils Ohlmeier [:drno]]

I guess it still freezes ;-)

Comment 11

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.