1156494 - Audio plays on device before being re-routed to BT headset after ending call

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[Greg Grisco]

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.

Comment 1

[Keven Kuo [:kkuo]]

Hi! Steven,

Looks like audio channel issue.
Could your team help to take a look? Thanks

--
Keven

Comment 2

[Alastor Wu [:alwu]]

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 :)

Comment 3

[Keven Kuo [:kkuo]]

(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

Comment 4

[Alastor Wu [:alwu]]

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.

Comment 5

[Alastor Wu [:alwu]]

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

Comment 6

[Bobby Chien]

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

Comment 7

[Michael Vines [:m1] [:evilmachines]]

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

Comment 8

[Bobby Chien]

(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.

Comment 9

[Alastor Wu [:alwu]]

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