1022981 - [B2G][Flame][Browser][Microphone] User will still hear sound from microphone stream if it is paused

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[Rachel Pribble [:rpribble]]

Attachment: Video.3gp

Description:
If the user creates an audio stream between the Flame Firefox OS browser and the Firefox Nightly desktop on a laptop, then pauses the microphone on one device, they will still hear audio from the microphone stream even though it's paused.

Repro Steps:
1) Update a Flame to BuildID: 20140609040203
2) Connect to http://mysecondwebrtc.appspot.com/ on the Flame and on Firefox Nightly desktop on a pc
3) On both the Flame and pc, select the microphone, input the remote client ID from the other device, & tap register
4) After establishing a microphone stream, tap pause on the local video on the Flame

Actual:
User will still hear audio from the Flame microphone stream when it is paused, and vice versa.

Expected:
Audio feed pauses as expected.

v2.0 Environmental Variables:
Device: Flame v2.0 MOZ ril
BuildID: 20140609040203
Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa
Gecko: 9305a8ec77fe
Version: 32.0a1
Firmware Version: v10G-2


Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/11229/
See attached: Video, logcat

Comment 1

[Rachel Pribble [:rpribble]]

Qawanted for results on Buri 2.0.

Comment 2

[pete siphantong [:Petes]]

The issue does not occur on the Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140609103029
Gaia: d283b742a12ac43ec087f45b02d3817cf7ddab69
Gecko: 68ac46c1b1f7
Version: 32.0a1 (2.0) MOZ
Firmware Version: v1.2device.cfg

Comment 3

[Joshua Mitchell (Inactive)]

QA-Wanted to check Flame 1.4 - if it repro's there also check Flame 1.3

Comment 4

[pete siphantong [:Petes]]

The issue does not occur on the Flame 1.4, audio feed pauses as expected

Environmental Variables:
Device: Flame 1.4
Build ID: 20140611000202
Gaia: d1cf95dc5e8b2f52148487291318542f1396608e
Gecko: a8bb6b76696b
Version: 30.0 (1.4) 
Firmware Version: v10G-2

Comment 5

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

What "Pause" are you selecting?

Note that there is no "pause" (or Mute) button on that page.  The only pause that would show up is for the (remote) video element, which is an incoming stream from the far end.

Pausing that should stop local playback from the far end.  It will not affect either microphone stream.  It's simply a video element, not 2-way video call control element.

It's unclear which end was "paused", and which end heard audio in this state.  If you pause on A, B will still hear you.  If a Mute (track.enable = false) control was added, that will mute your microphone.  (See http://mozilla.github.com/webrtc_landing/pc_test.html for an example.)

Comment 6

[Joshua Mitchell (Inactive)]

Needing info Pete and / or Rachel to address comment 5

Comment 7

[Rachel Pribble [:rpribble]]

Hi Randell,

I was pressing pause located at the bottom of the screen after tapping register on what appears to be a media player (with no video).  According to the test case I was following (https://moztrap.mozilla.org/manage/case/11229/) with only microphone enabled, pressing pause on the Firefox OS device should stop the sound stream heard on the Firefox pc desktop.

If this is incorrect, I either misunderstood the test case, or it needs updating. :)

Comment 8

[pete siphantong [:Petes]]

(In reply to Randell Jesup [:jesup] from comment #5)
> What "Pause" are you selecting?
> 
> Note that there is no "pause" (or Mute) button on that page.  The only pause
> that would show up is for the (remote) video element, which is an incoming
> stream from the far end.
> 
> Pausing that should stop local playback from the far end.  It will not
> affect either microphone stream.  It's simply a video element, not 2-way
> video call control element.
> 
> It's unclear which end was "paused", and which end heard audio in this
> state.  If you pause on A, B will still hear you.  If a Mute (track.enable =
> false) control was added, that will mute your microphone.  (See
> http://mozilla.github.com/webrtc_landing/pc_test.html for an example.)

I was pressing same pause button as Rachel, located on the bottom of Remote Video

Comment 9

[Joshua Mitchell (Inactive)]

Flame 2.0 = Repro
Flame 1.4 = NO repro

Regression 

QA-Wanted for Regression Window

Comment 10

[Jason Smith [:jsmith]]

Just to make sure I understand the above comments - the bug you are claiming here is that while I have a audio P2P call active between Flame --> Desktop Fx, if I pause the audio stream on the Flame side & talk into the mic for Flame, then Desktop Fx still hears the sound generated on the Flame device. Am I understanding this correctly?

Comment 11

[Rachel Pribble [:rpribble]]

Yes! That is correct.

In an audio-only call between a Flame and Firefox desktop, pausing the stream on the Flame then talking in to the Flame while it is paused results in the Firefox desktop still hearing the audio.

Comment 12

[Jason Smith [:jsmith]]

Okay - that's a functional regression then on something that should work in P2P.

Comment 13

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

(In reply to Jason Smith [:jsmith] from comment #10)
> Just to make sure I understand the above comments - the bug you are claiming
> here is that while I have a audio P2P call active between Flame --> Desktop
> Fx, if I pause the audio stream on the Flame side & talk into the mic for
> Flame, then Desktop Fx still hears the sound generated on the Flame device.
> Am I understanding this correctly?

If that "worked" in 1.4, that was a bug - pressing "pause" on a video element (local video or remote) simply stops it from playing.  It has no effect on the stream going to the peerconnection.

The pc_test page allows access to the video controls, but they're not necessary meaningful/useful for realtime video.  

To mute the microphone, check "Disable Audio" in the top line.

So, this bug should be about it being incorrect on 1.4 - pausing the element should not mute the microphone - and the testcase given is incorrect.  If you replace "I pause the local video" with "I disable local microphone" (etc) then it may be correct - validate on desktop-desktop first.

Bumping back down to 2.0? pending verification of what's being tested

Comment 14

[Jason Smith [:jsmith]]

Ah. Re-reading bug here, this is invalid. The only video tag that displays on my test site is the video from the remote peer. Pausing it would just stop you from hearing the person remote responses on the Flame device.

Comment 15

[John Thomas [:Johnt]]

This test case IS valid regarding 1.4. Comment 13 recommends that the wording be changed from "I pause the local video" with "I disable local microphone".

Comment 16

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case has been updated in moztrap:

https://moztrap.mozilla.org/manage/case/11229/