If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED INVALID

Status

()

Core
WebRTC
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: rpribble, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Points:
---
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(b2g-v2.0 affected)

Details

(Whiteboard: [2.0-flame-test-run-1]ft:loop, URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8437325 [details]
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
(Reporter)

Comment 1

3 years ago
Qawanted for results on Buri 2.0.
Keywords: qawanted

Updated

3 years ago
Component: Gaia::Browser → WebRTC
Product: Firefox OS → Core

Updated

3 years ago
blocking-b2g: --- → backlog
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA-Wanted to check Flame 1.4 - if it repro's there also check Flame 1.3
Flags: needinfo?(jmitchell)
Keywords: qawanted
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
Flags: needinfo?(jmitchell)
Keywords: qawanted
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.)
Needing info Pete and / or Rachel to address comment 5
Flags: needinfo?(rpribble)
Flags: needinfo?(psiphantong)
(Reporter)

Comment 7

3 years ago
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. :)
Flags: needinfo?(rpribble)
(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
Flags: needinfo?(psiphantong)
Flame 2.0 = Repro
Flame 1.4 = NO repro

Regression 

QA-Wanted for Regression Window
Flags: needinfo?(jmitchell)
Keywords: regression, regressionwindow-wanted
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?
Flags: needinfo?(rpribble)
(Reporter)

Comment 11

3 years ago
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.
Flags: needinfo?(rpribble)
Okay - that's a functional regression then on something that should work in P2P.
blocking-b2g: backlog → 1.4?

Updated

3 years ago
blocking-b2g: 1.4? → 2.0?

Updated

3 years ago
Whiteboard: [2.0-flame-test-run-1] → [2.0-flame-test-run-1]ft:loop

Updated

3 years ago
blocking-b2g: 2.0? → 2.0+
(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
blocking-b2g: 2.0+ → 2.0?
Flags: needinfo?(rpribble)
Flags: needinfo?(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.
Status: NEW → RESOLVED
blocking-b2g: 2.0? → ---
Last Resolved: 3 years ago
Flags: needinfo?(rpribble)
Flags: needinfo?(jsmith)
Keywords: regression, regressionwindow-wanted
Resolution: --- → INVALID
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
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".
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
Test case has been updated in moztrap:

https://moztrap.mozilla.org/manage/case/11229/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.