Closed Bug 1043813 Opened 10 years ago Closed 10 years ago

[B2G][Flame]Volume level is very low at max setting

Categories

(Firefox OS Graveyard :: AudioChannel, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S5 (26sep)
blocking-b2g 2.1+
Tracking Status
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: bkerensa, Assigned: gerard-majax)

References

Details

(Keywords: dogfood, regression, Whiteboard: [2.1-flame-test-run-2][fullflash-smoketest])

Attachments

(3 files)

When making calls the volume level at max is very low and it is much harder to hear calls then on other platforms. Tested with nightly on a Flame handset.
Version: 2.1.0.0-prerelease
Platform: 34.0a1
Build: 20140805040204
Component: General → AudioChannel
Summary: Volume level is very low → [b2g] Volume level is very low at max setting
[Blocking Requested - why for this release]:
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Summary: [b2g] Volume level is very low at max setting → [B2G][Flame]Volume level is very low at max setting
[Blocking Requested - why for this release]: Call volume is too loud on max setting to the point user cannot hear other caller.
blocking-b2g: --- → 2.1?
Paul: do you know who could help us with this?
Flags: needinfo?(paul)
I just tested the volume again and I put it at one bar and the volume level seems identical and when I increased it to max during the call there was no noticeable change in volume. Mind you I noticed someone on Twitter said the lowest volume setting is too loud on the Flame.
302 mwu, this is out of my area of expertise.
Flags: needinfo?(paul) → needinfo?(mwu)
Requesting qawanted for branch checks.

Not only is the volume far too low, the volume controls do not change the volume. It's the same level of too-quiet whether the controls are at the highest or lowest point.
Dietrich - are you sure this is a regression already? I've only seen info for it occurring on 2.1 and no evidence of anyone checking 2.0 or 1.4 yet.
Flags: needinfo?(dietrich)
Hm, I'm not sure. I seem to remember it being louder before. But human senses and memory are a lie.
Flags: needinfo?(dietrich)
Hah. Fair enough. Branch checks are under-way.
Can you please provide the base version you were using?  I was unable to repro on the same nightly build nor on today's engineering builds for 2.1 or 2.0.

2.1 nightly
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

2.1 engineering
BuildID: 20140814004506
Gaia: 5e074831f9ddacdf6f622a6dffaecb626f740be8
Gecko: de1d3c229e5a
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

2.0 engineering
BuildID: 20140814024604
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: abdb13f41d68
Platform Version: 32.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(bkerensa)
2.1 User
BuildID: 20140814040202
Platform: 34.0a1

Not sure how to grab the Firmware or Gaia info. But Dietrich and others have been able to reproduce on their own hardware too.
Flags: needinfo?(bkerensa)
Unable to reproduce this issue on the build the user provided with either V122 or v123 bases for flame. Was always able to adjust the volume higher on the DuT during a call. Adjusted all volumes in settings to both extremes with no problems seen. In comment 11 branch checks were done without success and I was just trying to get the bug on an original build with various base firmwares.

Environmental Variables: Nightly build
Device: Flame Master
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master) 
Firmware Version: v122
-----------------------------------------------
Environmental Variables: Nightly build
Device: Flame Master
BuildID: 20140805040204
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master) 
Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
I'm using the OTAs on Nightly channel. Maybe you have better hearing than I do. I went to a lot of super loud shows when I was young.
Cody can you try flashing to yesterdays 2.1 and do an OTA and then attempt to reproduce, perhaps that's the difference we need?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga) → needinfo?(croesch)
Sorry.........no luck there either.

Flashing Nightly 2.1 to 8/14 build then OTAing to today's 8/15 build does not cause an issue with calls being too quiet and not being able to adjust volume.

Environmental Variables: Nightly Build
Device: Flame Master
Build ID: 20140815040204
Gaia: 9979fccc6321be72cd17370f3a20c65bc376af33
Gecko: c9f8cc9ce89c
Version: 34.0a1 (Master)
Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(croesch) → needinfo?(pbylenga)
Is there anything else myself or Dietrich can offer to help isolate this?
Maybe the firmware used will reveal something? Run the following command
adb shell getprop t2m.sw.version

First 3 of the last 4 digits is the Firmware, mine ends in '1230' and is v123.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(bkerensa)
Attached image Results
That command generates no return for me but other adb commands work fine.
Flags: needinfo?(bkerensa)
Dietrich, can you run Th above since mine is not outputting anything useful?
Flags: needinfo?(dietrich)
Three people on our test team have taken a shot at this bug to reproduce, but we've had no success at reproducing this. As a result, I'm going to have to remove QA keywords for now, since there's it doesn't look like we're going to be able to help here unless we get better clarification on STR.
Keywords: dogfood
(In reply to Jason Smith [:jsmith] from comment #21)
> Three people on our test team have taken a shot at this bug to reproduce,
> but we've had no success at reproducing this. As a result, I'm going to have
> to remove QA keywords for now, since there's it doesn't look like we're
> going to be able to help here unless we get better clarification on STR.

STR are:
1. Make a call with volume set to lowest setting 
2. Listen to call volume
3. Increase call volume to max and notice no distinguishable change
4. Decrease volume back to low while still on call notice no change
QA-Wanted to attempt Repro with the updated STR (comment 22). If we get a Repro, please do a branch check.
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage+]
(In reply to Benjamin Kerensa [:bkerensa] from comment #19)
> Created attachment 8474702 [details]
> Results
> 
> That command generates no return for me but other adb commands work fine.

Ditto. This command executes successfully, and returns nothing.
Flags: needinfo?(dietrich)
Any reason why this command would not be working? Were hoping to provide info so this can be isolated.
Flags: needinfo?(pbylenga)
The command is working. You just don't have a t2m.sw.version property set in your build. Which build is that exactly?
(In reply to Fabrice Desré [:fabrice] from comment #26)
> The command is working. You just don't have a t2m.sw.version property set in
> your build. Which build is that exactly?

The nightly build and now OTA's Mozilla is providing for the flames?
What did you use as the base for the phone?  Or more specifically, have you ever flashed an OEM base image to your device?
Flags: needinfo?(pbylenga)
Flags: needinfo?(dietrich)
Flags: needinfo?(bkerensa)
PVT build of master + m-c via the scripts at https://github.com/Mozilla-TWQA/B2G-flash-tool. Switched to channel "nightly", also via the scripts there.
Flags: needinfo?(dietrich)
(In reply to Peter Bylenga [:PBylenga] from comment #28)
> What did you use as the base for the phone?  Or more specifically, have you
> ever flashed an OEM base image to your device?

As far as it was explained to me the Flame's came pre-flashed with the 123 base image and that once we then flashed the nightly https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame using shallow flash we were good to go?
Flags: needinfo?(bkerensa)
Oops, I missed that part of the question.

My device's current state is

* flashed base image
* flashed latest build via the QA scripts
* OTAs via nightly channel
Thanks for the information Dietrich and Benjamin!  I think the full flash may be the culprit as it changes more than just a gecko/gaia flash.

Okay, adding qawanted to try the following:

* flash base v123
* full flash with B2G-flash-Tool to yesterday's build
* OTA to today's nightly

attempt STRs provided in Comment 22.
Just to confirm I flashed v123 today then used shallow to upgrade to nightly then checked for OTA and am on today's nightly OTA and still same volume issues.
Using the steps from comment 32 and comment 22 I was unable to reproduce this issue.  The volume difference between maximum and minimum volume is not very large, but it is noticeable and I was always able to understand the other caller even at minimum volume.

Environmental Variables: (after updating)
Device: Flame Master
BuildID: 20140828040204
Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
Gecko: 3be45b58fc47
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(In reply to Jayme Mercado [:JMercado] from comment #35)
> Using the steps from comment 32 and comment 22 I was unable to reproduce
> this issue.  The volume difference between maximum and minimum volume is not
> very large, but it is noticeable and I was always able to understand the
> other caller even at minimum volume.
> 
> Environmental Variables: (after updating)
> Device: Flame Master
> BuildID: 20140828040204
> Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2
> Gecko: 3be45b58fc47
> Version: 34.0a1 (Master) 
> Firmware Version: v123
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

So you agree its not very large but would you be able to take a call on a city street at max volume? I know I cannot and others have experienced same. If indeed there is an increase in volume I would highly suggest we increase the max volume and create a larger gap. With this current volume situation I cannot dogfood.
I'm gonna assume we all make calls in different settings and we all have differently shaped faces and ears and different hearing abilities so there are many ways this could fail for people. 

I agree that the range between low and high volume is not enough.  The full loud setting should make me want to pull the phone away from my ear and it does not.  I've compared with a couple of other devices and we are quieter at the high end for sure. 

Let's increase the range.  Where does this code live? Can we tune in Gecko/Gaia or do we need more from the manufacturer?
Alex, have you seen this? I'm wondering if we're hitting a difference between the vendor's audio policy and ours, or some other difference in binary blobs..
Flags: needinfo?(mwu) → needinfo?(lissyx+mozillians)
(In reply to Michael Wu [:mwu] from comment #38)
> Alex, have you seen this? I'm wondering if we're hitting a difference
> between the vendor's audio policy and ours, or some other difference in
> binary blobs..

I remember seeing commits related to this, but I can't remember in which repo.
Flags: needinfo?(lissyx+mozillians)
> adb shell dumpsys media.audio_policy

I don't see any change at all in volume on my Kitkat build :(
Flags: needinfo?(bkerensa)
I just checked on a JB build on Etienne's phone. 

Running:
> adb shell dumpsys media.audio_policy

Shows that we are changing stream 0 volume properly, but I don't hear any change :(
I do reproduce this on my own Flame JB full flash.
We will need help from T2M to know where and when they fixed this.
Flags: needinfo?(bkerensa) → needinfo?(vchen)
Okay, even pushing /system/lib/ from v123 base image has no impact :(
(In reply to Benjamin Kerensa [:bkerensa] from comment #0)
> When making calls the volume level at max is very low and it is much harder
> to hear calls then on other platforms. Tested with nightly on a Flame
> handset.

Hi Benjamin,

could you describe what output did you use? speaker or receiver?
Flags: needinfo?(bkerensa)
(In reply to Wayne Chen [:xwaynec] from comment #47)
> (In reply to Benjamin Kerensa [:bkerensa] from comment #0)
> > When making calls the volume level at max is very low and it is much harder
> > to hear calls then on other platforms. Tested with nightly on a Flame
> > handset.
> 
> Hi Benjamin,
> 
> could you describe what output did you use? speaker or receiver?

I tried both Speaker and Receiver while Speaker was slightly louder the difference was not much (not compared to other mobile platforms or even my expectations as a user)

Receiver was the worst definitely
Flags: needinfo?(bkerensa)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Keywords: smoketest
For clarification, we are not seeing this issue to the same extent with the shallow flash as we are with the full flash. When using the full flash method we cannot hear either phone's audio and changes to the devices volume levels are not being reflected.
Not a smoketest blocker. This issue has been present for multiple months, which does not make this a blocker.
Keywords: smoketest
Flags: needinfo?(ktucker)
Whiteboard: [2.1-flame-test-run-2]
Whiteboard: [2.1-flame-test-run-2] → [2.1-flame-test-run-2][fullflash-smoketest]
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Flags: needinfo?(ktucker)
In case dupe bug 1055832 has been missed, I have the same issue (using a v2.0 build). While the volume is loud enough in a quiet room, it's not as soon as the environment is noisy (in a street, when there is some wind or passing cars).

I didn't have this issue with other FxOS phones I used in the past.
Reviewed in triage - regression, and maybe uncovering issues with full vs shallow flash, so blocking+.
blocking-b2g: 2.1? → 2.1+
(In reply to Dietrich Ayala (:dietrich) from comment #52)
> Reviewed in triage - regression, and maybe uncovering issues with full vs
> shallow flash, so blocking+.

Dietrich, while I agree with you, I could not find from where this discrepency comes from. My latest tries in comment 43 suggests it is not related to the /system/lib/ we are building.
Depends on: 1068587
Assignee: nobody → lissyx+mozillians
Maybe related to bug 1068587.
Current status when volume buttons looks to be ineffective:
 - dialpad tones
 - in call without speaker mode
 - in call with speaker mode
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Pushing those files:
> adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb
> adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb
> adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb
> adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb
> adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb
> adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb
> adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb

does not improve the situation
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Puhsing:

> adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/

does not improve the situation
(In reply to Alexandre LISSY :gerard-majax from comment #55)
> Current status when volume buttons looks to be ineffective:
>  - dialpad tones
>  - in call without speaker mode
>  - in call with speaker mode

Pushing both:
> adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/
+
> adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb
> adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb
> adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb
> adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb
> adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb
> adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb
> adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb

I get this situation:
 - volume change can be heard in call, with and without speaker mode.
Attached file JB Device PR
Michael, please find attached a PR that fixes the issue for JB images.
Attachment #8490756 - Flags: review?(mwu)
Note - we're going to need a patch here for KK too, as our one-off fullflash smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well.
(In reply to Jason Smith [:jsmith] from comment #60)
> Note - we're going to need a patch here for KK too, as our one-off fullflash
> smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well.

Thanks for bringing this: I could not find any trace of those files on my KK backup-flame (made out of v166 base image), so I assumed this one was not faulty. I'll check the status on Kitkat then.
I can confirm that the files from comment 58 fixed the issue for me (jb build).
On kitkat, having pulled files from v166 base image I see that they are now within /system/etc/acdbdata/
Attached file KK Device PR
Path have changed a bit, and it seems we do not have any snd_soc_msm on KK. As far as I could test, it fixes the issue on KK as well this way.
Attachment #8491515 - Flags: review?(mwu)
Attachment #8491515 - Flags: review?(mwu) → review+
Comment on attachment 8490756 [details] [review]
JB Device PR

Review comment on PR.
Attachment #8490756 - Flags: review?(mwu)
(In reply to Michael Wu [:mwu] from comment #65)
> Comment on attachment 8490756 [details] [review]
> JB Device PR
> 
> Review comment on PR.

Thanks, I just replied :)
Flags: needinfo?(mwu)
Do these files live in our code or do we need new base images from partner to fix this for our contributors who don't compile themselves?
The base images are fine. The issue is that we don't properly reuse the files from the backup-flame directory (pulled from a device flashed with a base image) when we generate our own images.
Comment on attachment 8490756 [details] [review]
JB Device PR

Updated PR: after discussing with mwu, let's use from repo.
Attachment #8490756 - Flags: review?(mwu)
Attachment #8490756 - Flags: review?(mwu) → review+
Flags: needinfo?(mwu)
Flags: needinfo?(vchen)
https://github.com/mozilla-b2g/device-flame/commit/b04c1a7d96f01a743f23a544870cd5be2c8d172e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Does this need approval requests for branches still?
Flags: needinfo?(lissyx+mozillians)
Target Milestone: --- → 2.1 S5 (26sep)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #72)
> Does this need approval requests for branches still?

I'm not sure, it's already on the proper branches.
Flags: needinfo?(lissyx+mozillians)
please full flash a KK tinderbox 2.1 build and verify its fixed on 2.1 branch.  thanks.
Keywords: verifyme
I tested this on Flame 2.1 and Flame 2.2 Full Flash with the KK Base.
On both branches, the volume seemed to work properly across the following areas of the device:

-Ringtone volume when receiving a call could be set appropriately loud and quiet.

-In-Call volume could be set appropriately loud and quiet.

-Dialer Touch Tone Keypad tones could be set appropriately loud and quiet (note, this required the user to change the Media volume, which must be done outside the Dialer app).

-Radio media volume could be set appropriately loud and quiet.

-YouTube media volume could be set appropriately loud and quiet (the volume range seemed a bit small when listening with headphones, but was still good when using the system speaker).

-Alarm volume could be set appropriately loud and quiet.


Environmental Variables:
Device: Flame 2.1
BuildID: 20140923003005
Gaia: 3a2947df41a480de1457a6dcdbf46ad0af70d8e0
Gecko: df42b05782aa
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.2 (Master)
BuildID: 20140922193018
Gaia: fe92ddd450e03b38edb2d465de7897971d68ac68
Gecko: 790f41c631cc
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Keywords: verifyme
Blocks: 1062554
See Also: 1062554
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: