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)
Tracking
(blocking-b2g:2.0+, 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)
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
Reporter | ||
Comment 1•10 years ago
|
||
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)
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Comment 3•10 years ago
|
||
Justin and Dominic: do either of you think this is a bug you could fix?
Flags: needinfo?(jdarcangelo)
Flags: needinfo?(dkuo)
Comment 4•10 years ago
|
||
(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)
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
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)
Updated•10 years ago
|
Flags: needinfo?(jdarcangelo)
Comment 7•10 years ago
|
||
Hi Yulong, would you help check it? Seems wrong volume handling in HAL per current finding, thank you.
Flags: needinfo?(wehuang) → needinfo?(youlong.jiang)
Comment 8•10 years ago
|
||
According to comment 6, change the component.
Component: AudioChannel → Vendcom
Comment 9•10 years ago
|
||
(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)
Comment 10•10 years ago
|
||
Hi Youlong, as discussed pls help update the status and findings in comment below, thanks.
Flags: needinfo?(youlong.jiang)
Comment 11•10 years ago
|
||
(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)
Comment 12•9 years ago
|
||
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
Comment 13•9 years ago
|
||
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.
Comment 14•9 years ago
|
||
verify with the latest base image v18B, it's fine
Comment 15•9 years ago
|
||
(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
Updated•9 years ago
|
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][POVB]
Target Milestone: --- → 2.2 S3 (9jan)
Comment 17•9 years ago
|
||
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)
Comment 18•9 years ago
|
||
Happen time 12:02
Comment 19•9 years ago
|
||
Comment 20•9 years ago
|
||
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
Comment 21•9 years ago
|
||
(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.
Updated•9 years ago
|
Flags: needinfo?(hlu) → needinfo?(zikui.yang)
Comment 22•9 years ago
|
||
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
Comment 23•9 years ago
|
||
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.
Description
•