Closed Bug 1093715 Opened 10 years ago Closed 9 years ago

[FM Radio] With the volume down, the user can still hear sound from the speaker and headphones

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.2 S3 (9jan)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: psiphantong, Unassigned)

References

()

Details

(Whiteboard: [2.1-exploratory-3][POVB])

Attachments

(3 files)

Attached file fr.txt
Description:
When user has the volume all the way down, sound can still be heard from the speaker and headphones 

Setup Steps:
1) Flame device is set to 319mb

Repro Steps:
1) Update a Flame device to BuildID: 20141104001202
2) Turn the volume all the way with the rocker
3) Go to the radio
4) Tap the speaker, tap speaker again


Actual:
sound can still be heard from the speaker and headphones 

Expected:
sound is muted from the speaker and headphones 


Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141104001202
Gaia: 8b0cf889ae0d48a9eb7ecdcb9b67590de45cc5e5
Gecko: 388b03efe92d
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency: 100%
See attached: video, logcat, https://www.youtube.com/watch?v=xlAWUOal5wc
This issue also reproduces on the Flame 2.2 and the Flame 2.0, the sound can still be heard from the speaker and headphones.

Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141104040207
Gaia: 3c50520982560ccba301474d1ac43706138fc851
Gecko: 54d05732f29b
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141104000201
Gaia: fe2167fa5314c7e71c143a590914cbf3771905a8
Gecko: 241e51806687
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
[Blocking Requested - why for this release]:

If the user has muted the volume it is expected that no sound will be heard from the raido app when in speaker or headphone mode. This breaks basic functionality.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
blocking-b2g: 2.0? → 2.0+
Justin and Dominic: do either of you think this is a bug you could fix?
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(dkuo)
(In reply to David Flanagan [:djf] from comment #3)
> Justin and Dominic: do either of you think this is a bug you could fix?

This should be an audio channel issue because in gaia only the system app is able to change the volume, but in this case it seems the FM radio api adjusted the volume from the gecko side so that the volume was unmuted.
Component: Gaia::FMRadio → AudioChannel
Flags: needinfo?(dkuo)
Though I put this in the audio channel component but I think it should be an issue on the FM gecko side, Randy might have idea about this, or know someone can help on this.
Flags: needinfo?(rlin)
Test the v188 base image also found this problem. 
I test this issue and try to run adb shell dumpsys, found the stream volume is correct on "AUDIO_STREAM_MUSIC stream" when volume step is zero on device, but sounds loudly. 
===========
Outputs dump:
- Output 2 dump:
 Sampling rate: 48000
 Format: 00000001
 Channels: 00000003
 Latency: 80
 Flags 00000002
 Devices 00000002 <--speaker
 Stream volume refCount muteCount
 00     1.000     00       00
 01     0.000     00       00
 02     0.000     00       00
 03     0.000     01       00  <--AUDIO_STREAM_MUSIC, step = 0 
 04     1.000     00       00
 05     0.000     00       00
 06     -1.000     00       00
 07     0.501     00       00
 08     0.000     00       00
 09     0.000     00       00
 10     1.000     00       00  <-- on flame device, I think FMRadio won't use this because it always keeps on 1 and never changes even I just the volume by hw rock button and can feel the volume changes.

I think it's flame's device audio HAL issue and it needs partner to check this.

Hi Wesley, 
Could you forward this problem to flame's partner? Thanks.
Flags: needinfo?(rlin) → needinfo?(wehuang)
Flags: needinfo?(jdarcangelo)
Hi Yulong, would you help check it? Seems wrong volume handling in HAL per current finding, thank you.
Flags: needinfo?(wehuang) → needinfo?(youlong.jiang)
According to comment 6, change the component.
Component: AudioChannel → Vendcom
(In reply to Wesly Huang from comment #7)
> Hi Yulong, would you help check it? Seems wrong volume handling in HAL per
> current finding, thank you.

wesly -

about this issue, our Vals has reproduce, and also we'll follow your previous analysis and keep handle asap.

tks.
Flags: needinfo?(youlong.jiang)
Hi Youlong, as discussed pls help update the status and findings in comment below, thanks.
Flags: needinfo?(youlong.jiang)
(In reply to Wesly Huang from comment #10)
> Hi Youlong, as discussed pls help update the status and findings in comment
> below, thanks.

hi wesly -

we doubt there maybe exist some logic bug in gecko/gaia when switch audio channel path between speaker and headset in FM, but no more actions setting volume when take switch handle. 

also we found there is volume sync action in audioflinger when set non-zero value, but no sync and set max value if mute audio. so we'll try to dig this point to keep forward.

tks.
Flags: needinfo?(youlong.jiang)
Hi Wesly,
    Update this bug status:
It caused by AudioPolicyManager when foxfire upgrade from V1.3 to V2.0
There some difference in AudioPolicyManager between V1.3 and V2.0
In details, it couldn't sync volume from headset mode to speaker mode just when volume index=0.
in the function: status_t AudioPolicyManager::checkAndSetVolume(...)
//this condition could be satisfied that lead to volume sync failed.
     if (volume != mOutputs.valueFor(output)->mCurVolume[stream] ||
             force) {

The related patch would be committed after Qualcomm CE reviewed. Thanks!


dongsheng.zou
sorry, there is a type error in above comment. After corrected as below.

//this condition couldn't be satisfied that lead to volume sync failed.
verify with the latest base image v18B, it's fine
(In reply to Mike Lien[:mlien] from comment #14)
> verify with the latest base image v18B, it's fine

Looks like we can close it now.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][POVB]
Target Milestone: --- → 2.2 S3 (9jan)
Hi Hubert
This issue still exist on flame 2.0/2.1/2.2
Flame 2.0 build:
Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7c7daab470fb
Build-ID        20150108000200
Version         32.0
Flame 2.1:
Gaia-Rev        ed2e278753e8c9301ba322dcf2c3591f5928408d
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/127a0ead5f83
Build-ID        20150108001214
Version         34.0
Flame 2.2 build:
Gaia-Rev        d4dac29613076bdba3cb8adc217deadb08a2ac20
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/70de2960aa87
Build-ID        20150108010221
Version         37.0a1
Reproduce rate 5/5
Refer to logcat1093715.txt and video1093715.mp4
Flags: needinfo?(hlu)
Attached file logcat1093715.txt
Happen time 12:02
Attached video video1093715.mp4.MP4
This fixed is based on base image changement.
Currently only mozilla-central apply the latest base image: v18D (bug 1117859 comment 5)

Wait for v2.1 and v2.0 changement
(In reply to Elie from comment #17)
> Hi Hubert
> This issue still exist on flame 2.0/2.1/2.2
> Flame 2.0 build:
> Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7c7daab470fb
> Build-ID        20150108000200
> Version         32.0
> Flame 2.1:
> Gaia-Rev        ed2e278753e8c9301ba322dcf2c3591f5928408d
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/127a0ead5f83
> Build-ID        20150108001214
> Version         34.0
> Flame 2.2 build:
> Gaia-Rev        d4dac29613076bdba3cb8adc217deadb08a2ac20
> Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/70de2960aa87
> Build-ID        20150108010221
> Version         37.0a1
> Reproduce rate 5/5
> Refer to logcat1093715.txt and video1093715.mp4

Hi, Elie,

Please see comment 20.
Also, please reconfirm this bug after patch (bug 1117859) uplifts to v2.1 and v2.0.
Thanks.
Flags: needinfo?(hlu) → needinfo?(zikui.yang)
This issue verified successfully on Flame 2.2:
Gaia-Rev        f5e481d4caf9ffa561720a6fc9cf521a28bd8439
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/bb8d6034f5f2
Build-ID        20150111010223
Version         37.0a1
Reproduce rate 0/5
This issue verified successfully on Flame2.1&2.2
Flame 2.0:
Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/296e19e6edcb
Build-ID        20150122000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
Flame 2.1 build:
Gaia-Rev        2055fc40a8bd2af1908979cb45da6b7d1c4ced0b
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/38ac70ca969b
Build-ID        20150122001404
Version         34.0
Device-Name     flame
FW-Release      4.4.2
Status: RESOLVED → VERIFIED
Flags: needinfo?(zikui.yang)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: