User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; BRI/2; .NET4.0C) Steps to reproduce: 1. From the Home Screen->Open the Camera 2. Switch to video mode 3. Press the Video Camera to start a recording 4. Talk at a reasonable volume while recording the video 5. End the recording 6. Press the Play button at the top of the page 7. Listen for Audio Actual results: The audio on the recording is at a volume that is too low to hear properly. This occurs even with all volume settings at the max. The volume also remains low when playing the video on another device (like a PC). Expected results: The video's audio plays at a level that can easily be heard by the user.
Found on Daily Unagi build from 11/28/2012: 20121128071138
Depend on Bug:814326, that would fix the content volume isn't large enough.
Depends on: 814326
Status: UNCONFIRMED → NEW
Ever confirmed: true
The recording clips voice level sounds ok on PC.
Assignee: nobody → rlin
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
push AudioFilter.csv into device still can't enlarge the recording audio volume. Will check the android platform cam-recorder audio recording performance also.
No update for a while - how's this coming Randy?
Try to fix bug 821576, but recording sound seems not large enough, need partner help to check.
Depends on: 821576
Request partner help to fine-tune the acoustic performance already. They will provide solution later.
ETA from partner?
Randy, who on the partner side are you waiting for? Let us know if we can contact them for an update.
Does not seems like a Gaia bug, moving component.
Component: Gaia::Video → Hardware
QA Contact: mozillamarcia.knous
Cc the mail (In reply to Faramarz (:faramarz) from comment #10) > Randy, who on the partner side are you waiting for? Let us know if we can > contact them for an update. Hi Faramarz, I have forwarded the mail loop to you. You can see the owner and they are checking this issue now.
Target Milestone: B2G C4 (2jan on) → B2G C3 (12dec-1jan)
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
Partner has passed the amss(modem) image for us and found the recording file's sound level is similar as the android device.
Thanks Randy. What's the next step for this bug?
Because this fix is on OEM's amss image(modem side), is it possible for developer/qa to update this and verify this issue isn't related to b2g?
(In reply to Randy Lin [:rlin] from comment #14) > Partner has passed the amss(modem) image for us and found the recording > file's sound level is similar as the android device. Am I reading this correctly: recording file sound amplitude = A A -> android = acceptable volume level A -> B2G = too quiet ? (In reply to Randy Lin [:rlin] from comment #16) > Because this fix is on OEM's amss image(modem side), is it possible for > developer/qa to update this and verify this issue isn't related to b2g? What would that entail? We don't seem to have the option to flash an unagi to stock Android (at least here in Berlin) but we do for an Otoro. Would that suffice?
(In reply to Andrew Overholt [:overholt] from comment #17) > (In reply to Randy Lin [:rlin] from comment #14) > > Partner has passed the amss(modem) image for us and found the recording > > file's sound level is similar as the android device. > > Am I reading this correctly: > > recording file sound amplitude = A > A -> android = acceptable volume level > A -> B2G = too quiet > Yes > > (In reply to Randy Lin [:rlin] from comment #16) > > Because this fix is on OEM's amss image(modem side), is it possible for > > developer/qa to update this and verify this issue isn't related to b2g? > > What would that entail? We don't seem to have the option to flash an unagi > to stock Android (at least here in Berlin) but we do for an Otoro. Would > that suffice? Partner has passed the unagi/otoro change for us, It needs use partner's tool to flash amss image into device. Maybe you can ask Kanru to help this.
Talked to rlin, this is a similar case as bug 823045 This is an OEM-related issue and it's also hardware-dependent. Fix done for unagi or otoro devices is nice but shipping hardware will likely require further tuning from the OEM side. Let's track this for 1.0 Talked to Andrew already so I am minusing this one directly
blocking-basecamp: + → -
When will the Unagi/Otoro fixes ship in nightly builds? I'm still seeing this.
talked to rlin, this will require a radio image change. do we really want to take this change?
(In reply to Joe Cheng [:jcheng] from comment #21) > talked to rlin, this will require a radio image change. do we really want to > take this change? The user impact seems pretty bad. What do you think, m1?
There's not really any action for the Mozilla team here to fix this bug like comment 19 says. But yep, user impact is pretty bad.
Whiteboard: [waiting on partner as of Jan 3] → [waiting on partner as of Jan 18]
Parter has given me the "amss radio image" for me and verified the recording file's sound level is similar to the android version. Can I distribute this change for those who want to verify?
TEF? again as with blocking-basecamp, since this is not part of the build being delivered, TEF+ probably isn't a good flag tracking this work given that all TEF+ needs resolution within a few days.
blocking-b2g: tef+ → tef?
Whiteboard: [waiting on partner as of Jan 18] → [waiting on partner as of Jan 18][NPOTB]
We can leave this tef+ since we haven't yet verified the fix and this has [NPOTB] in the whiteboard (thanks for adding that).
blocking-b2g: tef? → tef+
Hi Alex, Who can help to verify this issue? The partner's fix shouldn't upload on bugzilla.
(In reply to Randy Lin [:rlin] from comment #27) > Hi Alex, > Who can help to verify this issue? > The partner's fix shouldn't upload on bugzilla. We can call this fixed on our end if it's resolved in mvine's builds, and we can leave NPOTB in the whiteboard until that time.
(Not sure what NPOTB was supposed to mean --- moz builds? --- but looks like we're all good here.)
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [waiting on partner as of Jan 18][NPOTB]
NPOTB = not part of the build
Marking fixed based on comment 29.
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → fixed
Smoke Test Regression Build 20130130070201 gaia: f7f5a0cd17e3d04308cc5850b254947e127122b9 gekco:066b9d7cf30884a001db22bde3ae939c02718062 Dec 5th kernel ,pmem_adsp_size=13631488 The video does not play back sound loud enough to hear it with out putting the device up to your ear. Repro frequency : 5/5 times on 3/3 devices
Issue fail Test Case 2478: [Video] Play the video you recorded. Check for video and sound. UCID: Videoplay-007 As a user, I can play and pause a video, so that I can get the video going and pause when I need to stop Build ID: 20130130070201 Kernel: Dec 5 Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/4593f3e765eb Gaia f7f5a0cd17e3d04308cc5850b254947e127122b9
Whiteboard: testrun 4
Gecko http://hg.mozilla.org/releases/mozilla-b2g18/rev/3f905f0ca9ce Gaia ecca2ee860825547d5e1109436b50b74dfe9261e Build 20130212070205 Also tested the master build Gecko - 36525224b14e Gaia - 869e16dfdc3 Build 20130212031203 Bug still occurs on both builds listed. Audio is still very quiet.
Issue reproduces on multiple Unagi devices. Issue reproduces both builds: Nightly Build: Build ID: 20130214070203 December 5th Kernel Gaia: 6544fdb8dddc56f1aefe94482402488c89eeec49 Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/d1288313218e -and- Master Build: Build id 20130214032850 Dec 5th Kernel Gaia: remote="hgmozillaorg" revision="6ba3c0dfb2ee"/> Gecko: remote="hgmozillaorg" revision="aceeea086ccb"/>
Can we get clarify if this patch was uplifted for v1.0.1 or not? if this is just a mozilla-central patch, then why was it tef+'d? Last seen on unagi, v1.0.1 nightly build: Gecko http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/059a7e0badf7 Gaia 4164424049f9caa4e6b26aefe3a4fa7421451b2b BuildID 20130217070201 Testers are still seeing this problem on the v1.0.1 branch. reopening until someone can resolve this properly with an explanation. Thanks, Tony
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hi Tony, This issue can be fixed by updating the amss image which provided by partner. On gecko side, we has no patch for this issue. Does the geekphone has the same problem?
it will make sense to verify this on an Ikura/Inari. i believe this bug was to be kept tef+ to understand the status when we have a final device.
Tony, Randy what's the status there ?
Test the final device and found the recording sound volume is still small, send mail to partner and ask them to check this problem.
I Googled for "android set recording volume" and the consensus on the Webs seems to be that you cannot modify the video recording microphone gain on the Android platform, only the playback volume.
The final device's OEM has known this problem and they are doing the acoustic parameter fine-tuning stuff now.
status-b2g18: fixed → affected
status-b2g18-v1.0.0: fixed → wontfix
status-b2g18-v1.0.1: --- → affected
NPOTB since it seems to be on the OEM side.
Whiteboard: testrun 4 → testrun 4, [NPOTB]
Whiteboard: testrun 4, [NPOTB] → testrun 4, [NPOTB][target 28/2]
Removed [target 28/2] because [NPOTB]
Whiteboard: testrun 4, [NPOTB][target 28/2] → testrun 4, [NPOTB]
Video recorded has very low audio. Issue is still found on Unagi Build ID: 20130225070200 Kernel: Dec 5 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3a5a27992a75 Gaia: 5691a16fff8e1403c75ed9d6f3a443b7e58198c6 Testcase id: https://moztrap.mozilla.org/runtests/run/859/env/305/?pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=2478 UCID: videoplay-007, daily smoketest Master Build ID: 20130228030934 Kernel Date: Dec 5 Gecko: http://hg.mozilla.org/mozilla-central/rev/b0e08db3bc2a Gaia: 932f716cdb437e5e166f9e960a92127cc014c9d7
Whiteboard: testrun 4, [NPOTB] → testrun 4, [NPOTB], testrun 5.1
In reference to Comment 47 Test Case # 2478 UCID: videoplay-007 https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-id=2478
requires fix from partner
No info here for quite a while. Do we need to continue to block on this issue?
Dietrich, we are discussing this case with the partner in mails, actually. Based on Song Shenyang's information, this bug was fixed and the fix was committed yesterday. We need someone to verify the fix.
Verified fixed in unagi pvt pub 2013-04-10 build.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
Hi, Please promote this to v1train and v101.
John, can you assist with this checkin-needed request please?
(In reply to Walter Chen from comment #53) > Hi, Please promote this to v1train and v101. Walter, can you please clarify what exactly needs to be uplifted? I cannot find any link (href or otherwise) to code that needs to be uplifted or landed.
Flags: needinfo?(jhford) → needinfo?(wachen)
For this bug, there is nothing to do in gecko/gonk side and it needs unagi OEM's amss radio image update.
Should this be POVB then?
You need to log in before you can comment on or make changes to this bug.