Steps to reproduce: 1. From Settings/Bluetooth, connect to BT headset 2. From Music app, select a track and play it 3. Make a phone call from device 4. End the phone call Expected Result: After call ends, streaming audio should be routed back to BT headset Actual Result: After call ends, on device there can be heard the dial tone then a brief period where streaming music is heard before the music re-routes to BT headset.

Hi! Steven, Looks like audio channel issue. Could your team help to take a look? Thanks -- Keven

Hi, Greg, Do you mean that the music would come out from the speaker in brief period after the call ended? I can't reproduce this on the m-c. In step3, I tried both making a call and answering a call, then hang up the call. But the result is that the music would be out from the BT headset after the call ended. Could you provide your test Gecko version? Thanks :)

(In reply to Alastor Wu [:alwu] from comment #2) > Hi, Greg, > Do you mean that the music would come out from the speaker in brief period > after the call ended? > > I can't reproduce this on the m-c. Hi! Alastor, This case is occurring on v2.2. -- Keven

Thanks, Keven. I found that the music would come out from the speaker when the ringtone start, instead of end the call. I will check what is its root cause.

This issue is caused by the drawback of the present audio channel design. This issue can be solved after landing the Bug 1113086. Ringtone start > 04-21 17:37:21.568 8314 8314 I Gecko : DD | ACS, Register agent, type = 5 Because Gecko can't get the correct visible state, so all visible audio can be playback > 04-21 17:37:21.728 8314 8314 I Gecko : DD | ACS, visible audio, type = 5 > 04-21 17:37:21.728 8314 8314 I Gecko : DD | ACA, NotifyAudioChannelStateChanged, type = 5, canplay = 0 > 04-21 17:37:22.258 8314 8314 I Gecko : DD | ACS, visible audio, type = 1 > 04-21 17:37:22.258 9013 9013 I Gecko : DD | ACA, NotifyAudioChannelStateChanged, type = 1, canplay = 0 Change visibility, muted the music > 04-21 17:37:22.978 9013 9013 I Gecko : DD | ACA, SetVisibilityState, type = 1, visible = 0, canplay = 1

Greg, I posted feedback in meeting agenda. We suggest to correct behavior in next version (bug 1113086 in master).

Is this a regression in v2.2, or did v2.0 also behave this way?

(In reply to Michael Vines [:m1] [:evilmachines] from comment #7) > Is this a regression in v2.2, or did v2.0 also behave this way? Michael, yes, 2.x all behave this way. According to legacy design, gecko controls major audio channel routing logic. Gaia/apps could not manipulate or change any behavior to gecko. This legacy design could not fully handle these similar behaviors (foreground and background app transition). Gaia/systemApp get control in the new design next version (master). It could correctly behave this case.

Close this bug because we wouldn't land the code for v2.2.