1266346 - External video/sound playback is affected by Hello and viceversa

Status: RESOLVED INCOMPLETE

(Hello (Loop) :: General, defect, P3)

Description

[Adrian Florinescu [:aflorinescu]]

[Affected versions]: 
Nightly version: 48.0a1, build id: 20160420030213

Hello v 1.3.0		

[Affected platforms]:
- Ubuntu 14.04 x86
- Windows 7 x 64

[Prerequisites]:
Install the Hello 1.3.0 version on the profile you're testing with.
set the "loop.server" pref to "https://loop-dev.stage.mozaws.net/v0"

[Steps to reproduce]:
1. Launch Firefox.
2. Open a youtube video (chrome or other ff profile) / or a local mp4,mp3 with default player and start a playback.
3. Start Hello/Browse with a friend and click away (do not copy link or any other action).

[Actual Result - Ubuntu 14.04]:

The moment you click away, the playback stops or in the best case scenario freezes or/and the Hello will display "No camera or microphone found." Pressing Rejoin conversation will not work. 


Following errors are listed:

Browser Console:
Loop:Object { code: 400, errno: 203, error: "Unable to leave a room you have not…" }LoopRooms.jsm:840
Loop:Loop hawkRequest error: Object { code: 400, errno: 203, error: "Unable to leave a room you have not…" }MozLoopService.jsm:726

Ubuntu Console:
  Loop hawkRequest error:
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.
console.error: Loop: 
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.

Reproducible 70% of the cases. It does appear that the browser needs a certain state to get this bug reproduced. Therefore, if it the bug is not reproducible, restart the browser and try again. 
Sometimes I get the playback to freeze, but after 5-10 seconds it recovers and Hello works fine afterwards. For example in the case of an mp3 playback, the 5-10" playback freeze will be reproduced, after which the playback will resume.

[Actual Result - Windows 7]:
Browser Console:
No stores registered for event type  metricsLogJoinRoomdispatcher.js:88 

mp4 playback stopped: Only disconnecting Hello resumes the playback.
"No camera or microphone found." Hello message is not caught for win7 OS.


[Expected Result]:

Microphone and camera are successfully detected all the times. 
Playback is not affected by Hello starting up.
Hello is not affected by external resources using sound/video.

[Additional Notes]:
Windows10 and OSX do not replicate this behavior: external resource is not affected by Hello or the other way around.

Comment 1

[Ian Bicking (:ianbicking)]

Maire: do you know of any bugs like this, that appears to be interference between video playback and WebRTC?

It seems possible that the different behavior on different systems might be because of different media players or Flash-vs-HTML-video.

Comment 2

[Maire Reavy [:mreavy]]

Hi Ian, This isn't related to WebRTC.  I think you're running into either Flash vs HTML behavior or platform decoder vs software decoder behavior.  One easy thing you can try is to disable Flash across all the machines and see if the behavior changes.  If you need to dig into this more deeply with someone from Platform, I can put you in touch with jya or cpearce.

Comment 3

[Mark Banner (:standard8)]

Adrian, please can you try this all within either a non-e10s mode, or a non-e10s window? I have a hunch...

Comment 4

[Adrian Florinescu [:aflorinescu]]

48.0a1 BuildId 20160424030601
Bug reproduced for both win7 and ubuntu 14.04 in the non-e10s mode.

Comment 5

[Mark Banner (:standard8)]

Can we get a regression range for this, even if it is coarse at the Firefox version level to begin with, i.e. 45 vs 46?

I'm especially interested in: is this an issue in 45 (without any add-ons) or 46 (with or without add-on 1.3).

Comment 6

[Adrian Florinescu [:aflorinescu]]

Hello Mark,

Tried to identify a regression range for this, but with no luck.
Scenario with external mp4. resource played in backround.
Release 45 - not reproducible 
Release 46 - not reproducible (w/o 1.30 addon)
Release 46 - not reproducible (with 1.30 addon)

Luckily, I tried with Vidyo call on as external resource using mic/sound/camera and Hello is affected showing the no mic/camera detected while Vidyio had no issues whatsoever:(so in this case Hello was affected, not the external app. and in some cases FF froze while the external resource continued to work just fine).

Release 45 - not reproducible  but "no microphone or camera detected"
Release 46 - not reproducible (w/o 1.30 addon) but "no microphone or camera detected"
Release 46 - not reproducible (with 1.30 addon) but "no microphone or camera detected"

Further more I tried to get an actual range, but that provided a bit pointless since:
- version 48.0a1 doesn't have a "good".
- starting with the latest builds of version 47.0a1 and going lower I get blocked by "no microphone/no video camera selected" and FF most often freezes, or Hello starts behaving eratic. (behavior vary a bit betwen win7 and ubuntu, but since I didn't consider it relevant for the bug, i haven't pushed on it)
*Note: mozregression was ran with config param and addon:
config: loop.server "https://loop-dev.stage.mozaws.net/v0"
Addon: https://addons.mozilla.org/en-US/firefox/addon/firefox-hello-beta/versions/1.3.0

Also tried mozregression on builds without the addon and without the pref (with the embedded Hello only) , but when I reached the point where the FF requested non-E10s window to run Hello, I stopped considering it will lead nowhere.

Let me know if you have something else in mind that I could try.

Comment 7

[Mark Banner (:standard8)]

I'm sure I commented on this yesterday, but it doesn't seem to be here...

(In reply to Adrian Florinescu [:AdrianSV] from comment #6)
> Tried to identify a regression range for this, but with no luck.
> Scenario with external mp4. resource played in backround.
> Release 45 - not reproducible 
> Release 46 - not reproducible (w/o 1.30 addon)
> Release 46 - not reproducible (with 1.30 addon)

Ok, so that's good news if it isn't reproducible on 45/46 since that's where we want to ship 1.3.

> Luckily, I tried with Vidyo call on as external resource using
> mic/sound/camera and Hello is affected showing the no mic/camera detected
> while Vidyio had no issues whatsoever:(so in this case Hello was affected,
> not the external app. and in some cases FF froze while the external resource
> continued to work just fine).

This isn't really the same testing. Depending on which platform you're on (typically non-Mac), applications will "lock" the devices and prevent other applications accessing them. Since that is likely what is happening here, the WebRTC parts of Hello don't actually start up, and this then really becomes an invalid test.

> Let me know if you have something else in mind that I could try.

My only thought is to retry it on nightly, and if you can reproduce there with your original steps, then try it on aurora 48 / beta 47.

Comment 8

[Adrian Florinescu [:aflorinescu]]

Hello Mark,

It seems I created a bit of confusion with my above comment. The "not reproducible"  on comment 6 refers to the original steps. 
It also seems that i got myself misled on Windows7, where the bug is not reproducible: the playback is stopped by system/player, so it is not the same behavior as on Ubuntu.

Therefore, I redid all the tests on: Ubuntu 14.04, Ubuntu 15.10, Ubuntu 12.04, Windows7 x32 and Windows7 x64 (using addon 1.30 + loop server https://loop-dev.stage.mozaws.net/v0), and at this moment I can be fairly sure that we can exclude Windows7 as an affected platform.
One note though related to windows7: the behavior of the Hello / video playback is different in 49.0a1 than in 46.0, 47.0b1 ,48.0a2 : in 49.0a1 the playback and hello are both working without the video being automatically paused by system/player.  

Windows 7 x32 + x64
good 46.0      -       20160421124000 (playback is automatically system/player paused)
good 47.0b1    -       20160428004042 (playback is automatically system/player paused)
good 48.0a2    -       20160428004042 (playback is automatically system/player paused)
*good 49.0a1   -       20160428030218 (playback is not automatically system/player paused)


On Ubuntu systems, the situation differs a bit:
Please note that I redid the tests a few times, varying the Ubuntu machines I've tested on. What puzzles me and the reson I redid the tests a few times is that the behavior I'm listing below is not 100% accurate, aurora and nightly being the most affected by bug reproducibility variance. What stays the same is that 46 is stable in not reproducing the bug, while 49 Nightly most often does reproduce the bug.
More, the 64x build seems to reproduce less the issue as the 32x. What I find curios again is the fact that on Ubuntu 12.04, I only could reproduce the problem 5-10% of the time but it was only reproducible on one system out of 4 used. I couldn't spot the difference.

Sumary:
4 x 12.04 32b machines
2 x 14.04 32b machines
2 x 15.04 64b machines  
   


Ubuntu 12.04 x32

46.0 Build ID 20160421124000 Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
AR:
Hello works: bug not reproducible:
Console Output:
console.error: Loop: 
  invalid preference type getting loop.ot.guid


47.0b1 Build ID 20160425205003 Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0
AR:
Hello works: bug not reproducible:
Console Output:
console.error: Loop: 
  invalid preference type getting loop.ot.guid

48.0a2 Build ID 20160502004021 Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0
AR:
Hello works: bug not reproducible:
Console Output:
console.error: Loop: 
  invalid preference type getting loop.ot.guid

49.0a1 Build ID 20160502030207 User Agent 	Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
AR:
Hello works: bug not reproducible:
Console Output:
console.error: Loop: 
  invalid preference type getting loop.ot.guid


Ubuntu 14.04 x32

46.0 Build ID 20160421124000 Mozilla/5.0 (X11; Linux i686; rv:46.0) Gecko/20100101 Firefox/46.0
AR: 
Hello works: bug not reproducible:
Console Output:
console.error: Loop: 
  invalid preference type getting loop.ot.guid


47.0b1 Build ID	20160425205003 Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0
AR:
Hello doesn't work: bug not reproducible -> blocked by no camera or microphone detected
Console Error:
  Loop hawkRequest error:
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.
console.error: Loop: 
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.

48.0a2 Build ID	20160502004021 Mozilla/5.0 (X11; Linux i686; rv:48.0) Gecko/20100101 Firefox/48.0
Hello doesn't work: bug not reproducible -> blocked by no camera or microphone detected
Console Error:
  Loop hawkRequest error:
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.
console.error: Loop: 
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.

49.0a1 Build ID 20160502030207 Mozilla/5.0 (X11; Linux i686; rv:49.0) Gecko/20100101 Firefox/49.0
Hello doesn't work: bug reproducible and "no camera or microphone detected"
Console Error:
  Loop hawkRequest error:
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.
console.error: Loop: 
Object
    - code = 400
    - errno = 203
    - error = Unable to leave a room you have not joined.

Ubuntu 15.04 x64

46.0 - bug not reproducible
47.0b1 - bug not reproducible
48.0a2 - bug reproducible + no microphone/camera detected 
49.0a1 - bug reproducible + no microphone/camera detected

Comment 9

[Mark Banner (:standard8)]

So this seems to be Linux only.

From what I can tell, this is likely to be a resource availability issue or something... Chris, any ideas here?

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

I'm very confused as to what is the expected behaviour here, and what's the observed behaviour.

Is starting a Loop call supposed to pause playback of media in other tabs? I'm not familiar with how that works.

Is this an issue with Cubeb blocking the audio playback or somesuch? Given that it's Linux only, it could be a problem with the Linux audio subsystem.

A regression range would be helpful here.

Comment 11

[Ian Bicking (:ianbicking)]

(In reply to Chris Pearce (:cpearce) from comment #10)
> I'm very confused as to what is the expected behaviour here, and what's the
> observed behaviour.
> 
> Is starting a Loop call supposed to pause playback of media in other tabs?
> I'm not familiar with how that works.

We never had any particular intention for Loop to stop or not stop other media.  Since generally we don't do anything to stop multiple tabs from playing sound at the same time, I suppose we expect the same thing to happen with Loop.

From the original comment, this is the concerning issue:

> The moment you click away, the playback stops or in the best case scenario freezes 
> or/and the Hello will display "No camera or microphone found." Pressing Rejoin 
> conversation will not work. 

That the other audio plays or doesn't is less of a concern than the experience breaking here.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

If you set the pref media.suspend-bkgnd-video.enabled=false, does the bug go away?

Comment 13

[Adrian Florinescu [:aflorinescu]]

(In reply to Chris Pearce (:cpearce) from comment #12)
> If you set the pref media.suspend-bkgnd-video.enabled=false, does the bug go
> away?
No. With the preference true/false, the bug is still there.

Comment 14

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.