Description: The user executes two media recordings using the same stream in the same content process. While recording simultaneously, the user mutes only one stream, but both stream get muted. Repro Steps: 1) Update a Flame device to BuildID: 20141015001201. 2) Go to http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html 3) Select "Microphone", type "2" for number of recorders, and select "Setup". 4) Grant the permissions. 5) Select "Start Recording" for both "index 0" and "index 1". 6) After 4 seconds of generating sound, select "Mute Media Stream" under "index 0". 7) After 5 seconds of generating sound, select "Unmute Media Stream" under "index 0". 8) Select "Stop Recording" for both "index 0" and "index 1". 9) Play both blob URLs generated. Actual: Both recordings are muted after the first 4 seconds. Expected: Only 1st recording is muted after the first 4 seconds. The 2nd recording is NOT muted at all. Environmental Variables: Device: Flame 2.1 BuildID: 20141015001201 Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3 Gecko: 4853208cb48a Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 100% Link to failed test case: https://moztrap.mozilla.org/manage/case/10182/ See attached: logcat

This issue also reproduces on Flame 2.2 and 2.0: Flame 2.2 Device: Flame 2.2 Master KK (319mb) (Full Flash) Build ID: 20141015040201 Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6 Gecko: 62f0b771583c Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 36.0a1 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Flame 2.0 Environmental Variables: Device: Flame 2.0 KK (319mb) (Full Flash) Build ID: 20141015000206 Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00 Gecko: 24a2aa6bf1c4 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 32.0 (2.0) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Both recordings are muted when the user muted only 1 of 2.

Added video: http://youtu.be/VP9Nf3cQTcM

Not nominating this as a blocker, as this is just a test site

can we check whether this still reproduces, and if so, ni? Jim Porter, I believe with the recent works in audiostream, this might not reproduce anymore. Thanks!

Hi No-Jun, According to the STR of Comment 0, I still can repro this bug on latest Flame v2.0&2.1&2.2&3.0. Could you help with this bug again? Thank you very much. ---------------------------------------------------------------- Actual results: Both the recordings are muted. See attachments: verify_v2.2.MP4 and logcat.txt Reproduce rate: 4/4 ---------------------------------------------------------------- Device: Flame 2.0 build(Affected) Build ID 20150503160204 Gaia Revision 84898cadf28b1a1fcd03b726cff658de470282f0 Gaia Date 2015-04-03 21:42:36 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7280924bba4c Gecko Version 32.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150503.193837 Firmware Date Sun May 3 19:38:48 EDT 2015 Bootloader L1TC000118D0 Device: Flame 2.1 build(Affected) Build ID 20150503001202 Gaia Revision b4a03b7ee61de5a479b3cf0916f47e91a43b0f50 Gaia Date 2015-04-30 21:31:55 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/bcbfb2d04b15 Gecko Version 34.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150503.040110 Firmware Date Sun May 3 04:01:22 EDT 2015 Bootloader L1TC000118D0 Device: Flame 2.2 build(Affected) Build ID 20150503002500 Gaia Revision 8d14361337e608c8cdf165ea5034db5eda23b618 Gaia Date 2015-05-01 18:23:46 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cb7cb6597c91 Gecko Version 37.0 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150503.040203 Firmware Date Sun May 3 04:02:15 EDT 2015 Bootloader L1TC000118D0 Device: Flame 3.0 build(Affected) Build ID 20150503160200 Gaia Revision e18cce173840d6ff07fb6f1f0e0ffb58b99aab3e Gaia Date 2015-05-02 04:27:01 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/dc5f85980a82 Gecko Version 40.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150503.193941 Firmware Date Sun May 3 19:39:52 EDT 2015 Bootloader L1TC000118D0

Actually, Sotaro, would this bug be related to the omx driver? Or is it something fixable on the gaia side?

njpark, how can I test it? The following URL in comment 0 is invalid now. > 2) Go to http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1083413#c14, the new url is http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder/MediaRecorder.html but the links may not work there. Naoki, do you know who we should ask for the fix?

Jsmith was the one that wrote these test cases. They broke when the testcases git repo moved from mozilla to mozilla-b2g. I think it's just a matter of trying to fix it regardless of who the owner is for these web apps. I'm trying to fix it slowly by figuring out what's broken and fixing them.

Taking myself off needinfo. We're going to track the media test webapp breakage in a different bug.

[Tracking Requested - why for this release]: We can test this once Bug 1164721 is fixed.

Test case needs to be updated to this page: http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html QAWanted to see if this still occurs.

Hi Naoki, This bug still can be repro on latest Flame KK v2.5 and Aries KK v2.5 by the STR in comment 0 in "http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html". Could you help to look the bug agian? Thank you very much. Actual results: The Both recording are muted when the user muted only one while recording simultaneously. See attachment: FlameKK_v2.5.3gp and logcat_1846.txt Reproduce rate: 5/5 Device: Flame KK 2.5 (Affected) Build ID 20150823150207 Gaia Revision cddb9f610cbe03d0ca39d81bbdce46a0fca841ab Gaia Date 2015-08-23 03:34:38 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/4ccdd06e51d7209ba429196df7cab97bf66962db Gecko Version 43.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150823.184539 Firmware Date Sun Aug 23 18:45:51 EDT 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Aries KK 2.5(Affected) Build ID 20150823221817 Gaia Revision cddb9f610cbe03d0ca39d81bbdce46a0fca841ab Gaia Date 2015-08-23 03:34:38 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/4ccdd06e51d7209ba429196df7cab97bf66962db Gecko Version 43.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150823.214038 Firmware Date Sun Aug 23 21:40:46 UTC 2015 Bootloader s1

Sotaro-san, please use the following URL ( "http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html" ) instead of the url in step 2.

I seem to understand the cause of the problem. The test uses mediaRecorder.stream to mute/unmute the stream. MediaRecorder returns same stream that is given at "new MediaRecorder(stream)". Therefore, mediaRecorder.stream returns same MediaStream among multiple MediaRecoders, because all of them uses same MediaStream to create MediaRecorder.

It seems necessary to do similar thing to Bug 1073406. If mediaRecorder.stream returns MediaRecorder's media stream, the problem could be addressed.

FYI: diagram of MediaRecorder https://github.com/sotaroikeda/firefox-diagrams/blob/master/media/dom_media_MediaRecorder_FirefoxOS_2_5.pdf

(In reply to Sotaro Ikeda [:sotaro] from comment #20) > It seems necessary to do similar thing to Bug 1073406. If > mediaRecorder.stream returns MediaRecorder's media stream, the problem could > be addressed. MediaRecorder's spec say the following. It seems to prohibit to create new DOMMediaStream to wrap source MediaStream. > MediaRecorder > MediaStream stream > The MediaStream to be recorded. This will be the value of the stream attribute. See >[GETUSERMEDIA] for the definition of MediaStream. http://w3c.github.io/mediacapture-record/MediaRecorder.html#widl-MediaRecorder-stream

The test pass same MediaStream to 2 MediaRecorders. From comment 22, MediaStream.stream of the both 2 MediaRecorders becomes same. Then, applying "audioTracks[0].enabled = false" to one MediaRecoder mute also another MediaRecorder.

:pehrsons, is there a way to address the problem? Could MediaStream.clone() fix the problem? Though MdiaStream.clone() is not implemented yet?

This seems like an issue in the test. Gecko and the spec are behaving correctly. But making the test do what it's trying to do does require the ability to clone MediaStreams, either via clone() or the MediaStream constructor.

So muting is done by disabling the tracks. Yeah then gecko is behaving correctly. With clone() or MediaStream() constructors not implemented yet (working on it!), can you fix this by getting separate gUM() streams for each recorder?

nhirata, What do you prefer to fix the problem? It becomes clear that the mute works correctly.

Um, it seems to me that we should branch the test and disable it until clone() gets implemented while with the clone of the test, fixing the test w/ getting separate gUM() streams for each recorder. Is that correct? This would mean that we would have a test for cloning and a test with separate gUM() streams for each recorder. Johan, what do you think?

I'm not an expert in Media APIs, but these 2 scenarios look valid API integration tests to me.

Andreas - this is closely related to the muting stuff we talked about, and track cloning. Using muting-on-leaf-nodes should allow us to fix this. As you mention, right now it's operating as intended. Can you link it to the other muting bug, so the test can be fixed once track cloning and/or leafnode muting is available? Thanks

(In reply to Randell Jesup [:jesup] from comment #30) > Andreas - this is closely related to the muting stuff we talked about, and > track cloning. Using muting-on-leaf-nodes should allow us to fix this. Well, cloning would allow us to fix this, and the muting-on-leaf-nodes is really a blocker of cloning. > As > you mention, right now it's operating as intended. > > Can you link it to the other muting bug, so the test can be fixed once track > cloning and/or leafnode muting is available? Thanks Both made blockers of this bug.

This bug is specific to b2g.