[Video - Unagi] Volume is recorded at a very low volume while shooting video with the device camera and microphone.

VERIFIED FIXED in B2G C4 (2jan on)

Status

Firefox OS
Hardware
P3
normal
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: CSchmoeckel, Assigned: Firefox_Mozilla, NeedInfo)

Tracking

({smoketest, unagi})

unspecified
B2G C4 (2jan on)
ARM
Gonk (Firefox OS)
smoketest, unagi
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, blocking-basecamp:-, b2g18 affected, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 affected)

Details

(Whiteboard: [NPOTB], testrun 5.1)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
blocking-basecamp: --- → ?
Keywords: unagi
(Reporter)

Comment 1

5 years ago
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
blocking-basecamp: ? → +
Priority: -- → P3
The recording clips voice level sounds ok on PC.
Assignee: nobody → rlin

Comment 4

5 years ago
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
Flags: needinfo?(rlin)
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.
Flags: needinfo?(rlin)
Duplicate of this bug: 816608
Whiteboard: [waiting on partner as of Jan 3]

Updated

5 years ago
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
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?
Flags: needinfo?(rlin)
(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.
Flags: needinfo?(rlin)
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: + → -
blocking-b2g: --- → tef+
Keywords: smoketest
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?
Flags: needinfo?(mvines)
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.
Flags: needinfo?(mvines)

Updated

5 years ago
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
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.
Flags: needinfo?(mvines)
WORKSFORME
Flags: needinfo?(mvines)
(Not sure what NPOTB was supposed to mean --- moz builds? --- but looks like we're all good here.)
Status: NEW → RESOLVED
Last Resolved: 5 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

Comment 33

5 years ago
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
(Reporter)

Comment 34

5 years ago
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.

Updated

5 years ago
Depends on: 841614

Comment 36

5 years ago
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"/>
Duplicate of this bug: 841614
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?
Flags: needinfo?(tchung)
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 ?
Flags: needinfo?(rlin)
Test the final device and found the recording sound volume is still small, send mail to partner and ask them to check this problem.
Flags: needinfo?(tchung)
Flags: needinfo?(rlin)
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.

Updated

5 years ago
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]

Comment 47

5 years ago
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

Comment 48

5 years ago
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

Updated

5 years ago
Whiteboard: testrun 4, [NPOTB], testrun 5.1 → [NPOTB], testrun 5.1
requires fix from partner
Flags: needinfo?(Firefox_Mozilla)
Assignee: rlin → Firefox_Mozilla
No info here for quite a while. Do we need to continue to block on this issue?

Comment 51

5 years ago
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: 5 years ago5 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Hi, Please promote this to v1train and v101.
Keywords: checkin-needed
Duplicate of this bug: 874384
John, can you assist with this checkin-needed request please?
Flags: needinfo?(jhford)
(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.
Flags: needinfo?(wachen)
Should this be POVB then?
Keywords: checkin-needed
You need to log in before you can comment on or make changes to this bug.