Closed Bug 1082677 Opened 5 years ago Closed 5 years ago

[Music] When unplugging headphones, the music will be muted from the speaker

Categories

(Firefox OS Graveyard :: AudioChannel, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:2.0+, firefox34 wontfix, firefox35 wontfix, firefox36 fixed, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 verified)

VERIFIED FIXED
2.1 S9 (21Nov)
blocking-b2g 2.0+
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
b2g-v2.0 --- verified
b2g-v2.0M --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: psiphantong, Assigned: rlin)

References

()

Details

(Whiteboard: [2.1-flame-test-run-3])

Attachments

(6 files)

Attached file mh.txt
Description: 
When unplugging headphones, the music will be muted from the speaker

Repro Steps:
1) Update a Flame to 20141013001201
2) Open the Music app
3) Play a music, plug headphone, adjust the slider/volume 
4) Unplug the headphone > Tap play

Actual:
music is muted through the speaker

Expected:
music is heard through the speaker


Flame 2.1 

Device: Flame 2.1 KK (319mb) (Full Flash)
BuildID: 20141013001201
Gaia: d18e130216cd3960cd327179364d9f71e42debda
Gecko: 610ee0e6a776
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency: 80%
Link to failed test case: https://moztrap.mozilla.org/manage/case/5796/
See attached: video, logcat, https://www.youtube.com/watch?v=16gnlgSv-eU
This issue also reproduce on the Flame 2.2 KitKat Base (319mb) and the Flame 2.0 KitKat Base (319mb)(Full Flash), Music is muted through the speaker, user have to restart the phone to hear from the speaker again.

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
BuildID: 20141013040202
Gaia: 3b81896f04a02697e615fa5390086bd5ecfed84f
Gecko: f547cf19d104
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0


Flame 2.0

Device: Flame 2.0 KK (319mb) (Full Flash)
BuildID: 20141013000204
Gaia: 6effca669c5baaf6cd7a63c91b71a02c6bd953b3
Gecko: 54ec9cb26b59
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
The playback states are correct so looks like an audio channel issue.
Component: Gaia::Music → AudioChannel
[Blocking Requested - why for this release]:

The speaker will no longer play any audio until phone restart. Nominating this as a blocker.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
HI Wayne:
 Please help check this with Star!
Thanks!!
Shawn
Flags: needinfo?(waychen)
Hi Star, 

Could you please kindly look into this issue ?

Function broken, Can't recover until reboot phone; triage to set it to 2.0+.
Flags: needinfo?(scheng)
[SW version]
base image : v184, gecko + gaia : master branch

In Audio Manager, it got 1 headphone event and 1 headset event. 

I/AudioManager(  220): [star] aState 3 sHeadsetState 8   (aState 3 : SWITCH_STATE_HEADPHONE) [1]
I/AudioManager(  220): [star] aState 2 sHeadsetState c   (aState2 : SWITCH_STATE_HEADSET) [1]
(sHeadsetState |= AUDIO_DEVICE_OUT_WIRED_HEADSET;)
(sHeadsetState |= AUDIO_DEVICE_OUT_WIRED_HEADPHONE;)
 so the sHeadsetState is 0x0c
I/AudioManager(  220): [star] aState 1 sHeadsetState c


It's strange that the headphone & headset events are both sent to gecko. If these 2 events are sent correctly, we should set the correct state by setDeviceConnectionState(0x0c, AUDIO_POLICY_DEVICE_STATE_UNAVAILABLE,""). But the output device still is in 0x08 (headphone).


[1]enum SwitchState {
    SWITCH_STATE_UNKNOWN = -1,
    SWITCH_STATE_ON,
    SWITCH_STATE_OFF,
    SWITCH_STATE_HEADSET,          // Headphone with microphone
    SWITCH_STATE_HEADPHONE,        // without microphone
    NUM_SWITCH_STATE
  };

[2] enum audio_devices {
        // output devices
        DEVICE_OUT_EARPIECE = 0x1,
        DEVICE_OUT_SPEAKER = 0x2,
        DEVICE_OUT_WIRED_HEADSET = 0x4,
        DEVICE_OUT_WIRED_HEADPHONE = 0x8,
   }
Flags: needinfo?(scheng)
Hi, Rachelle


Could you help to request ODM partner(T2M) to look into this issue? Because it is not duplicated in v162 base image.

Thanks
Flags: needinfo?(ryang)
Hi Star, thanks for your feedback.

ni Wesly Huang as TAM of T2M account for more information , thanks !
Flags: needinfo?(ryang) → needinfo?(wehuang)
clear ni because comment 6
Flags: needinfo?(waychen)
Hi Youlong, would you check this issue? In comment#6 you can see the event sent to gecko is not consistent when headset plug/unplug. Thanks.
Flags: needinfo?(wehuang) → needinfo?(youlong.jiang)
Triage pre-emptively blocking. If vendor issue, please unblock.
blocking-b2g: 2.0? → 2.0+
(In reply to Wesly Huang from comment #10)
> Hi Youlong, would you check this issue? In comment#6 you can see the event
> sent to gecko is not consistent when headset plug/unplug. Thanks.

maybe audio patch mixed. we'll check and feedback asap.

tks.
Flags: needinfo?(youlong.jiang)
(In reply to youlong.jiang from comment #12)
> (In reply to Wesly Huang from comment #10)
> > Hi Youlong, would you check this issue? In comment#6 you can see the event
> > sent to gecko is not consistent when headset plug/unplug. Thanks.
> 
> maybe audio patch mixed. we'll check and feedback asap.
> 
> tks.

hi wesly -

for this issue, we've test on v188 30+ times, and not reproduce. and also your rep-rate is so high as 80%. so in my opinion, could you pls check the difference in gaia/gecko first.

tks.
ni Bobby to look into this
Flags: needinfo?(bchien)
Depends on: NewAudioChannel
Priority: -- → P2
Not reproducible in following versions.

------

Gaia-Rev        3d9cc667f4e929861a9a77c41096bbf5a9c1bde0
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/928b18f7d8ff
Build-ID        20141022001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880

Gaia-Rev        e91d99e4d96954f06383c00bb9d79598a697e310
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/8230834302c9
Build-ID        20141026160206
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880
More repro Steps:
1) Open the Music app
2) Play a music, plug headphone, adjust the slider/volume 
3) Unplug the headphone > Tap play (music play on speaker)
4) plug the headphone (music through headphone)
5) unplug/plug and play/stop music between steps 3) and 4)

Amend comment 15 results, this could reproduce with repeat steps 3) and 4) on Flame, 2.0, 2.1, 2.2.
ni Josh for potential escalation.
Flags: needinfo?(jocheng)
Not reproducible on Woodduck 2.0M. (20 trials)

== Build Information ==
Gaia-Rev        fdb8236d7d99061ef6bedc021fd6b482e1af3f5a
Gecko-Rev       3d95c1683ef5eb017bd15bc38ba111ddb1ad792e
Build-ID        20141024050313
Version         32.0
Device-Name     soul35
FW-Release      4.4.2
FW-Incremental  1414098327
FW-Date         Fri Oct 24 05:05:49 CST 2014
Potentially depend on bug 1088339.
Depends on: 1088339
Randy, please check this bug. Thanks.
Flags: needinfo?(rlin)
I had discussed Bobby about this issue yesterday and it should the same as Bug 1088339
The library in PVT full flash isn't the same as the v188 base image right now.
Bobby, could you do the shallow flash? (flash v188 base image first and flash gecko/gaia only)
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(rlin) → needinfo?(bchien)
(In reply to Randy Lin [:rlin] from comment #21)
...
> Bobby, could you do the shallow flash? (flash v188 base image first and
> flash gecko/gaia only)
Randy, have you done this test and made sure this is the solution for this bug?
Flags: needinfo?(rlin)
(In reply to Randy Lin [:rlin] from comment #21)
> I had discussed Bobby about this issue yesterday and it should the same as
> Bug 1088339
> The library in PVT full flash isn't the same as the v188 base image right
> now.
> Bobby, could you do the shallow flash? (flash v188 base image first and
> flash gecko/gaia only)

I already updated to v188. But the issue could be reproduced with repeat steps. I have 2 Flame for your investigation now. Let me know if you need it.
Flags: needinfo?(bchien)
Check the Bobby NG device and the symptom was changed.
1. I don't found the log in logcat pattern as Bug 1088339.
==
10-23 14:56:30.155   198  1551 E audio_hw_primary: adev_open_output_stream: Primary output is already opened
10-23 14:56:30.165   198  1551 D audio_hw_primary: adev_open_output_stream: exit: ret -17
10-23 14:56:30.165   198  1551 W AudioPolicyManagerBase: checkOutputsForDevice() could not open output for device 4
10-23 14:56:30.165   198  1551 E voice_extn: voice_extn_check_and_set_incall_music_usecase: Invalid session id 0
10-23 14:56:30.165   198  1551 E audio_hw_primary: adev_open_output_stream: Incall music delivery usecase cannot be set error:-22
10-23 14:56:30.165   198  1551 D audio_hw_primary: adev_open_output_stream: exit: ret -22
==
2. It can recover by re-insert/plug out the headset again. 
3. F/R rate is not as high as only flash PVT build.
4. Check the connect device on audio policy manager and the headset status is connected on speaker no sound case, it needs investigating.
Flags: needinfo?(rlin)
Check the reproduce step and Bobby plugs-in /plugs -out headset quickly (one loop ~ 3 sec)
It needs several minutes to found it and could be recover by re-plug in/out headset again.
That's why I can't reproduce it.
(In reply to Bobby Chien [:bchien] from comment #23)
> (In reply to Randy Lin [:rlin] from comment #21)
> > I had discussed Bobby about this issue yesterday and it should the same as
> > Bug 1088339
> > The library in PVT full flash isn't the same as the v188 base image right
> > now.
> > Bobby, could you do the shallow flash? (flash v188 base image first and
> > flash gecko/gaia only)
> 
> I already updated to v188. But the issue could be reproduced with repeat
> steps. I have 2 Flame for your investigation now. Let me know if you need it.

As discussion with Randy, according to HAL driver update in v188 image, bug 1088339 should be disappear from v188. However, a similar symptom could be created with same reproduce steps.  

The similar symptom is speaker can not play out music no matter repeating plug/unplug headset in reproduce steps. Once connecting adb, and trying to dump debug logs. Speaker is recovered, and could play music. This symptom is hard created again. As my testing, fail rate is 1 per 100 reproduce steps. (maybe 10mins)

Gaia-Rev        e91d99e4d96954f06383c00bb9d79598a697e310
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/8230834302c9
Build-ID        20141026160206
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880
Check another NG device and found the mediaserver keep dying. 
Hi YouLong, 
Could you check the logcat /kernel log for this?
Flags: needinfo?(youlong.jiang)
Flags: needinfo?(jocheng)
randy, if you find this bug should not be assigned to you, you can reassign it.
Assignee: nobody → rlin
Attached patch patch v1Splinter Review
From this comment
https://bugzilla.mozilla.org/show_bug.cgi?id=1082677#c6
We could call the setDeviceConnectionState(0x0c, AUDIO_POLICY_DEVICE_STATE_UNAVAILABLE,""). But it's invalid in AudioPolicyManagerBase.cpp:
status_t AudioPolicyManagerBase::setDeviceConnectionState(...)
...
    // connect/disconnect only 1 device at a time
    if (!audio_is_output_device(device) && !audio_is_input_device(device)) return BAD_VALUE;      

This patch can avoid the incorrect report headset status problem.
Attachment #8520530 - Flags: review?(mwu)
Comment on attachment 8520530 [details] [diff] [review]
patch v1

Review of attachment 8520530 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/AudioManager.cpp
@@ +235,5 @@
> +    if (sHeadsetState & AUDIO_DEVICE_OUT_WIRED_HEADPHONE) {
> +      AudioSystem::setDeviceConnectionState(AUDIO_DEVICE_OUT_WIRED_HEADPHONE,
> +                                            AUDIO_POLICY_DEVICE_STATE_UNAVAILABLE, "");
> +      sHeadsetState &= ~AUDIO_DEVICE_OUT_WIRED_HEADPHONE;
> +    }

Instead of clearing sHeadsetState in each if statement, I think it'll be better to do sHeadsetState = 0 at the end like the old code. Should be the same thing but simpler.
Attachment #8520530 - Flags: review?(mwu) → review+
Hi Randy:

I'm reviewing all T2M's Flame issues and see this one is already fixed however in comment#27 you asked Youlong for checking logcat /kernel log. 

Is this log checking still needed? Thanks.
Flags: needinfo?(rlin)
The comment#27 would be part of this issue.
I think t2m need to check this.
BTW, any update for this?
Flags: needinfo?(rlin)
Thanks Randy, so I still keep this issue open in my tracking list w/ T2M.
https://hg.mozilla.org/mozilla-central/rev/32fc7133b1c0
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Please request b2g32 and b2g34 approval on this patch when you get a chance.
Flags: needinfo?(rlin)
Target Milestone: --- → 2.1 S9 (21Nov)
Attached patch check-in.patchSplinter Review
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): NA
User impact if declined: User can't hear sound from speaker if they do this test step. And they will think this device is damaged.
Testing completed: By my self
Risk to taking this patch (and alternatives if risky): No
String or UUID changes made by this patch:N/A
Flags: needinfo?(rlin)
Attachment #8522621 - Flags: review+
Attachment #8522621 - Flags: approval-mozilla-b2g34?
Attachment #8522621 - Flags: approval-mozilla-b2g32?
Bhravana, we need this for AudioChannel. Many thanks.
Flags: needinfo?(bbajaj)
(In reply to Wesly Huang from comment #33)
> Hi Randy:
> 
> I'm reviewing all T2M's Flame issues and see this one is already fixed
> however in comment#27 you asked Youlong for checking logcat /kernel log. 
> 
> Is this log checking still needed? Thanks.

hi wesly -

we'll check logs in comment28  and feedback asap.

but I found this bug is rose by difference between pvt build and base image we provide. so I think it's necessary to check code sync mechanism from github.then, what you think?

tks.
Flags: needinfo?(youlong.jiang)
Flags: needinfo?(bbajaj)
Keywords: verifyme
Attachment #8522621 - Flags: approval-mozilla-b2g34?
Attachment #8522621 - Flags: approval-mozilla-b2g34+
Attachment #8522621 - Flags: approval-mozilla-b2g32?
Attachment #8522621 - Flags: approval-mozilla-b2g32+
Verify passed on Flame, this issue can't be repro on Flame2.0&2.1&2.2. Because the bug 1090143 still exist in Woodduck, so we can't verify this issue on Woodduck.
Attached: Verify_Woodduck_Music.mp4
Reproducing rate: 0/5
Flame 2.0 build:
Gaia-Rev        086a668942292168f312b3bb53e275fa0886fab1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a57b299c5cf2
Build-ID        20141117000200
Version         32.0

Flame 2.1 build:
Gaia-Rev        81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3572aa3e6766
Build-ID        20141117001201
Version         34.0
Flame2.2 build:
Gaia-Rev        ae3a84acaab80a5b35d5542d63e68462273c8a1b
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/2d0a51ef828d
Build-ID        20141117160200
Version         36.0a1
Hi Youlong, as mentioned in meeting pls help analysis and clarify comment#27 and comment#28, tks.
Flags: needinfo?(youlong.jiang)
(In reply to Wesly Huang from comment #45)
> Hi Youlong, as mentioned in meeting pls help analysis and clarify comment#27
> and comment#28, tks.

Dear wesly -

we've analysis log info from comment#28 and found so many core service die before media server. check audio system and got that audio path configured error as follow,

...................
167 11-04 21:49:49.082 I/ServiceManager(  189): service 'media.audio_flinger' died
168 11-04 21:49:49.082 I/ServiceManager(  189): service 'media.player' died
169 11-04 21:49:49.082 I/ServiceManager(  189): service 'media.camera' died
....................
 81 11-04 21:49:45.962 E/audio_route(15212): Control 'RX2 MIX2 INP2' doesn't exist - skipping
 82 11-04 21:49:45.962 E/audio_route(15212): Control 'RX1 MIX2 INP2' doesn't exist - skipping
 83 11-04 21:49:45.962 E/audio_route(15212): Control 'MI2S_DL_HL Switch' doesn't exist - skipping
 84 11-04 21:49:45.972 E/audio_route(15212): Control 'MI2S_DL_HL Switch' doesn't exist - skipping
...................

but keep fall back check, found log file is incomplete, then we couldn't get the root cause of error config for audio path.

tks.
Flags: needinfo?(youlong.jiang)
Youlong: I thought what Randy expect in comment#27 and comment#28 is the reason why media server kept dying. Is the log enough for you to investigate this?

@Randy: pls feel free to correct if I have wrong understanding. Thanks.
Flags: needinfo?(youlong.jiang)
Flags: needinfo?(rlin)
As per comment 43, changing status to verified since it's has been verified
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Youlong means he can't find the time stamp when the media server start to died.
If it happen again, I think we should create another bug for this issue.
Flags: needinfo?(rlin)
Attached video Video_Woodduck2.0.MP4
Verify passed on Woodduck, this issue can't be repro on Woodduck 2.0m.

Woodduck version:
Gaia-Rev        3a98f1287fa7b604891220ba5d86982ae8f9971e
Gecko-Rev       03d3ab62d5b07b915434f2d1d68495ad5915ecd2
Build-ID        20141120103003
Version         32.0
Thanks Randy, then I will remove this one from my issue tracking list w/ T2M. Alined w/ Youlong in review meeting.
Flags: needinfo?(youlong.jiang)
You need to log in before you can comment on or make changes to this bug.