Closed Bug 1186135 Opened 5 years ago Closed 5 years ago
[Camera][Video] Recording a video, no chime indicator that recording has started or ended
Description: When a user begins to take a video capture from the Camera app, they will observe that no chime can be heard from when recording begins or when recording is ending. This is a regression from previous builds and is not sure whether this is by design. Repro Steps: 1) Update a Aries to 20150721140411 2) Open the Camera app 3) Switch to video 4) Start recording a video Actual: Camera is silent when video recording begins and ends Expected: Audio chime is heard when beginning to record a video Environmental Variables: --------------------------- Device: Aries 2.5 Build ID: 20150721140411 Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e Gecko: d7a9e44717b7 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 42.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Device: Flame 2.5 BuildID: 20150721010202 Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e Gecko: 3a4bfa5d2d02 Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423 Version: 42.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 ************************ Issue DOES NOT REPRO on 2.2 for flame devices Results: Audio chime is heard when beginning to record a video Device: Flame 2.2 BuildID: 20150721002506 Gaia: e1e6317f17a840b19af9dbb25f5a771d8d9fa161 Gecko: 1bc400014f71 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 --------------------------- Repro frequency: 5/5 See attached: video- https://youtu.be/7pCgNigwLyo logcat
QA Whiteboard: [QAnalyst-Triage?]
Whiteboard: [3.0-Daily-Testing], [Spark] → [2.5-Daily-Testing], [Spark]
[Blocking Requested - why for this release]: Noticeable regression. Requesting a window, I highly suspect this to be related to the other audio management issues. bug 1130350 and dependencies
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
b2g-inbound regression window: Last Working Device: Flame BuildID: 20150720073224 Gaia: a47e0c58dd1340a17be7cc96ccd90fcad15a922b Gecko: f7d9b77a7afb Version: 42.0a1 (2.5 Master) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 First Broken Device: Flame BuildID: 20150720074629 Gaia: a47e0c58dd1340a17be7cc96ccd90fcad15a922b Gecko: e9b4a2b76fb3 Version: 42.0a1 (2.5 Master) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0 Gaia is the same so it's a Gecko issue. Gecko pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=f7d9b77a7afb&tochange=e9b4a2b76fb3 Caused by changes made in Bug 1184055.
Alastor, can you take a look at this please? Here is another issue that might have been caused by the landing for Bug 1184055.
In preliminary analysis, the BrowserElementAudioChannel didn't get the active notification from the AudioChannelService, so the system didn't open the audio chime sound. Still finding more details.
I found that the BrowserElementAudioChannel (BEAC) would not receive the event from the AudioChannelService(ACS), when we are playing multiple audio channel sound in the same process. The first sound can work well, but the second sound would get stuck, for unknown reason. In this case, we have two types sound, "content" and "notification". The "content" channel is used to paused other sound when the recording starts (in DOMCameraControl.cpp), and the "notification" channel is the start sound of the recording. So, the situation happens like that, (1) "content" starts, register agent, send active event to content BEAC (2) BEAC gets event, and pass it to the system app (3) system app open the "content" (4) "notification" starts, register agent, send active event to content BEAC (5) nothing happens Here is the problem! The BEAC can't get the "notification" active event from the ACS , so the system app would not open it! ---- To verify the problem (can't play multiple audio in same process), I use Dominic's test app . If you play the normal audio first, then the you want to play content one, the later audio can't be playback and vice versa. The later audio can't be playback. However, after the above steps, if you pause the content audio, the BEAC can receive the inactive event! And then every operations would be back to normal! Steps like that, (1) Start normal - ok (2) Start content - fail, BEAC can't receive the active event (3) Pause content - ok, BEAC can receive the inactive event (4) Start content - ok, BEAC can receive the active event
Assignee: nobody → alwu
Hi, Baku, Do you have any idea about comment5? Very appreciate :)
I cannot reproduce this issue. I wrote a test. Am I doing something wrong?
Attachment #8638569 - Flags: review?(alwu)
Hi, Baku, Your test logic is correct, if the issue happens, that you can't playback audio2. However, I'm not sure whether the issue can be reproduce on the desktop. Since the mochitest didn't have a gaia competing logic, they are all playable. The problem we got is that we muted the audio in initial, then we can't get the open command from the system app. And one questions, Where you declare the permission "audio-channel-alarm" in the test? The issue can only be reproduced when we playback different audio channel types audio. If you have any idea or question, please discuss with me :) Thanks!
Regression - blocking
blocking-b2g: 2.5? → 2.5+
[Bug issue] We can't playback multiple audio channel type in the same window. --- [Root cause] Because we only used one variable to store the active status of the audio channel in TabChild.cpp, it should be stored independently by per channel. --- [Issue detail] The |mAudioChannelActive| is used to store the active status of the audio channel of the tab. It is false by default. Think about this case, > Playback the "content" type first, and then "notification" type. (1) When we playback the "content" type channel, we send the active event (active=true). Then, the |mAudioChannelActive| would be changed to true. (2) When we playback the "notification" type channel, it can't be playback. Because the |mAudioChannelActive| is already set to true, we can't send the notification again. In this bug, we would playback "content" first, then "notification" during the recording. The "content" type is used to pause other sound, because we can't playback other sound during the camera recording. The "notification" type is used to playback the chime sound.
Attachment #8636724 - Attachment is obsolete: true
Try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=edd891d10ba2
Modify the compile warning, and new try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=85906e4543fc
Attachment #8642367 - Attachment is obsolete: true
New patch and try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1c4e24126be
Attachment #8642377 - Attachment is obsolete: true
Comment on attachment 8642792 [details] [diff] [review] Independent audio channel active flag Hi, Ehsan, Sorry to bother you, Could you help me review this patch? The root cause analysis is in the comment10. In this patch, I stored the active status per channel so that the TabChild can send the correct audio channel notification event. Very appreciate :)
Attachment #8642792 - Flags: review?(ehsan)
Comment on attachment 8642792 [details] [diff] [review] Independent audio channel active flag Review of attachment 8642792 [details] [diff] [review]: ----------------------------------------------------------------- r=me with the below addressed. ::: dom/audiochannel/AudioChannelService.h @@ +25,5 @@ > #ifdef MOZ_WIDGET_GONK > class SpeakerManagerService; > #endif > > +#define NUMBER_OF_AUDIO_CHANNELS (uint32_t)AudioChannel::System + 1 Please use (uint32_t)AudioChannel::EndGuard_ instead. That is guaranteed to always remain up to date. ::: dom/ipc/TabChild.h @@ +640,4 @@ > bool mAsyncPanZoomEnabled; > CSSSize mUnscaledInnerSize; > > + nsTArray<bool> mAudioChannelsActive; Nit: please use an auto array with a buffer size of 10.
Attachment #8642792 - Flags: review?(ehsan) → review+
Try-server result. https://treeherder.mozilla.org/#/jobs?repo=try&revision=5d7e8f899979
This bug has been verified as "pass" on latest Nightly build of Flame master and Aries master by the STR in Comment 0. Actual results:Audio chime is heard when beginning to record a video. See attachment: Aries v2.5.3gp Reproduce rate: 0/5 Device: Aries KK 2.5(Pass) Build ID 20150810003528 Gaia Revision 09dea2d5ff21cdb56da35fe4aa5bf4c90cf1da7f Gaia Date 2015-08-09 17:11:47 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/0e269a1f1beb Gecko Version 42.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20150810.000017 Firmware Date Mon Aug 10 00:00:24 UTC 2015 Bootloader s1 Device: Flame KK v2.5(Pass): Build ID 20150810150206 Gaia Revision 9a8880a95ee4a4aea7895d4e2bcab31bc49ea281 Gaia Date 2015-08-10 16:01:11 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/8cba870a352c Gecko Version 43.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150810.183734 Firmware Date Mon Aug 10 18:37:46 EDT 2015 Firmware Version v18D v4 Bootloader L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.