1003025 - [madai] the music is shortly played for the incomming call

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[Seil Park]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

1. After BT paring and connected , play the music
2. ringing incomming call


Actual results:

The music is shortly played to the speaker between the ring circle.

Audio Track(Music) is called from gecko for ringing. 



Expected results:

The ring should be played only.

Comment 1

[Jason Smith [:jsmith]]

QA Wanted to see if we can reproduce on 1.3.

Comment 2

[Rob MacDonald [:robmac]]

Flagging Mike for audio policy feedback - Mike, was Harly working on this?

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

(In reply to Jason Smith [:jsmith] from comment #1)
> QA Wanted to see if we can reproduce on 1.3.

Issue is NOT reproducible on Buri 1.3.
I paired Buri to another phone via bluetooth, played music, received a call, and incoming call sound wasn't mixed with the music; music was paused and I can only hear phone ringing. Issue repro rate: 0 out of 5 attempts.

Tested on:
Device: Buri 1.3 MOZ
BuildID: 20140429024001
Gaia: caab7a78f0c04913f48a3051259663ee85625906
Gecko: f84a8ffbc552
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 4

[Preeti Raghunath(:Preeti)]

Issue repro rate: 0 out of 5 attempts

>> Does this mean the issue can be in backlog for monitoring it?

Comment 5

[Hema Koka [:hema]]

Which device is this happening on - bug is marked madai? We don't have madai devices yet for testing.

Also per QA I see that it is not reproducible on 1.3 Buri, but is it happening on 1.4 Buri? 

+ Dkuo to see if we caused any regressions here...

Comment 6

[Jason Smith [:jsmith]]

Adding qawanted to see if we can reproduce this on 1.4 Buri.

Comment 7

[Pi Wei Cheng [:piwei] (inactive)]

I was able to reproduce this only with the speaker. Comment 3 was tested with a headset plugged in (I didn't think it would make a difference but I was wrong).

Issue is reproducible 80% on today's 1.4 and 1.3. After bluetooth pairing, the first ring of an incoming call via speakers could be mixed with music from Music app. After the 1st ring, music is correctly paused and only ringer sound can be heard. Repro rate seems higher if user stays on Music app when a call comes.

Comment 8

[Jason Smith [:jsmith]]

Marco - I thought it was expected behavior to have the ringer play with music in the background if the music app was playing when the incoming call came in. We implemented this as a feature in 1.2 to my understanding.

Can you confirm or is this a bug?

Comment 9

[Marco Chen [:mchen]]

I suspect it is a bug about 3 seconds timing issue from Window Manager.
Please refer to the link as below.

https://bugzilla.mozilla.org/show_bug.cgi?id=908525#c49

Comment 10

[Dominic Kuo [:dkuo]]

(In reply to Hema Koka [:hema] from comment #5)
> + Dkuo to see if we caused any regressions here...

I think comment 0 is more like bug 843955, the background music plays shortly between the ringtone/alert cycles, it's because before the ringtone repeat again, there is a gap that the audio element is preparing to play the ringtone, so the audio competing policy thinks there is no active audio channel in the foreground, then the background audio channel(music) is able to resume again, and when the ringtone is ready and plays again, the music is interrupted, that's why we can hear the background music between the ringtone cycles.

To fix this issue, the technique I used in bug 958470 could work I guess. If we use the audio context(web audio) instead of the audio element to play the ringtone, then the background music won't be able to play shortly because the audio context will occupy the active channel, so the audio competing policy will treat the audio context as an endless stream and will not release the active channel to the others. But note that once the audio context is created, it will trigger the audio channel changes, even there is no source connected, so remember to clean/flush it after we used the audio context, or all the other channels won't be able to play any sound after we answered the calls.

(In reply to Marco Chen [:mchen] from comment #9)
> I suspect it is a bug about 3 seconds timing issue from Window Manager.
> Please refer to the link as below.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=908525#c49

Comment 7 and what Marco mentioned should be a similar issue but the result is actually different, the 3 seconds delay of the visibility change will cause the background music and the ringtone mix together, that means the user will hear the music and ringtone at the same time, which is bad ux for the users. For this issue, bug 927862 should fix this because the visibility should be correct set after it landed.

Comment 11

[Preeti Raghunath(:Preeti)]

Backlog for now.

Comment 12

[soyeon]

I'm sorry to tell you that the issue is happening on 2.0 version.

I guess that the problem was not solved before.

what the issue is going on?

Is there anybody who can know the situation and tell me the process of that?

Comment 13

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Dominic

Since bug#927862 is now fixed, is this one also fixed?

Thanks

Comment 14

[Dominic Kuo [:dkuo]]

It should if bug 927862 does its work, but I didn't try myself so could be 100% sure, can we request qawanted? thanks.

Comment 15

[Dominic Kuo [:dkuo]]

(In reply to Dominic Kuo [:dkuo] from comment #14)
> It should if bug 927862 does its work, but I didn't try myself so could be
could not I mean
> 100% sure, can we request qawanted? thanks.

Comment 16

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Mike -

Per Comment#14, this issue should already fixed in master/2.1, since i don't have a BT headset with me, could you help to check if that is the case?

Thanks

Vance

Comment 17

[Mike Lien[:mlien]]

no this issue doesn't fixed with with v2.0 and v2.1 and I think the symptom is the same with bug1043749
this issue doesn't need BT necessary, just clarify the STR

1. play music
2. ringing incomming call

Comment 18

[Mike Lien[:mlien]]

Hi Dominic,

This problem will happen while music playing on the "foreground" and might different with bug958470
If music playing on the "background", audio channel switch is fine and has no any mixed audio between media and ringer

Do you have any idea?

Comment 19

[Dominic Kuo [:dkuo]]

(In reply to Mike Lien[:mlien] from comment #18)
> Hi Dominic,
> 
> This problem will happen while music playing on the "foreground" and might
> different with bug958470

Yes, it looks different but the technique I used(use audio context instead of audio element) could possibly fix this issue(I can write a quick patch to prove it if needed), but I think bug 927862 should already fixed this bug, since the root cause of this bug is one of the major problem we want to address in bug 927862.

> If music playing on the "background", audio channel switch is fine and has
> no any mixed audio between media and ringer
> 
> Do you have any idea?

The root cause of this bug was, music and callscreen are both "visible(document.hidden = false)" when music is playing in the foreground then an incoming call rings, what you described sounds like if music is playing in the foreground/background will affect the result, this shouldn't happen after bug 927862 landed, because the callscreen should block the foreground music and let music's visibility become "hidden", then music will be interrupted entirely.

Can anyone first verify if bug 927862 is included while testing? thanks!

Comment 20

[Rachelle Yang [:ryang][[e-mail]]]

[Blocking Requested - why for this release]:
partner requested as blocker. nominate to 2.0 ?

Comment 21

[howie [:howie]]

Triage: blocking. Hi Star, can you take a look at this? Thank you.

Comment 22

[Star Cheng [:scheng]]

AFAIK, bug 927862 can *not* completely resolve this issue. It reduces the duration time of audio leak form ~3000ms to ~300ms. Bug 1034001 can completely fix this symptom which mentioned in comment 0. 

Hi, alive

If there is any wrong information I said, please feel free to point it out.

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Star Cheng [:scheng] from comment #22)
> 
> AFAIK, bug 927862 can *not* completely resolve this issue. It reduces the
> duration time of audio leak form ~3000ms to ~300ms. Bug 1034001 can
> completely fix this symptom which mentioned in comment 0. 
> 
> Hi, alive
> 
> If there is any wrong information I said, please feel free to point it out.

Very True.

Comment 24

[Eric Chou [:ericchou] [:echou]]

Per offline discussion with Star, he told me that right now he doesn't have a comprehensive solution for this. The best solution is getting bug 1034001 solved, which is targeted to be done by 2.2. 

For 2.0, Rachelle, could you help check if our partner can accept current 2.1 status? The audio leak is actually not noticeable (to me) right now. Please see the video (http://youtu.be/usFruRDcPy8) I recorded.

Comment 25

[Rachelle Yang [:ryang][[e-mail]]]

Hi Eric,

Thanks for your feedback and video. I found it's fine, and should be acceptable.
May I know if any improvement is done on 2.1 on this audio handling that we might be able to apply on 2.0 which is partner currently requested ?

Thank you very much!

Comment 26

[Eric Chou [:ericchou] [:echou]]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #25)
> Hi Eric,
> 
> Thanks for your feedback and video. I found it's fine, and should be
> acceptable.
> May I know if any improvement is done on 2.1 on this audio handling that we
> might be able to apply on 2.0 which is partner currently requested ?

Please see comment 19 and comment 22. I believe the improvement came from the fix of bug 927862. So you may want to revisit that bug and see if the patch of bug 927862 could be merged to partner's branch.

Comment 27

[Rachelle Yang [:ryang][[e-mail]]]

Triage to denominate it for 2.0 for now since bug 927862 is a huge patch; too risky to land on 2.0.

Comment 29

[Wesly Huang (EPM)]

Hi Wayne: per triage discussion we don't nom. this issue for 2.0 however provide a workaround patch for partners' try. Would you help put it here? Thank you.

Comment 30

[Wayne Chen [:xwaynec]]

Attachment: audio_policy.patch

Hi Wesly,

Partner could try it first.

Comment 31

[Wesly Huang (EPM)]

Thanks Wayne!

Comment 32

[Seil Park]

(In reply to Wayne Chen [:xwaynec] from comment #30)
> Created attachment 8516680 [details] [diff] [review]
> audio_policy.patch
> 
> Hi Wesly,
> 
> Partner could try it first.

I recommend temp_mute after ringing, connecting.
===================================================
    // Audio_Framework: Music is mixing with ringing in FFOS2.0, after MT call
    if (state == AudioSystem::MODE_RINGTONE) {
        for (size_t i = 0; i < mOutputs.size(); i++) {
            AudioOutputDescriptor *desc = mOutputs.valueAt(i);
                setStrategyMute(STRATEGY_MEDIA, true, mOutputs.keyAt(i));
                setStrategyMute(STRATEGY_MEDIA, false, mOutputs.keyAt(i), MUTE_TIME_MS*8,
                    getDeviceForStrategy(STRATEGY_MEDIA, false));
        }
    }

    // Audio_Framework: Music is mixing with ringing in FFOS2.0, after MT call
    if (state == AudioSystem::MODE_IN_CALL) {
        for (size_t i = 0; i < mOutputs.size(); i++) {
            AudioOutputDescriptor *desc = mOutputs.valueAt(i);
                setStrategyMute(STRATEGY_MEDIA, true, mOutputs.keyAt(i));
                setStrategyMute(STRATEGY_MEDIA, false, mOutputs.keyAt(i), MUTE_TIME_MS*4,
                    getDeviceForStrategy(STRATEGY_MEDIA, false));
        }
    }
=====================================================
In v2.0, if the user just receive a call, the music keeps to play after the call is connected.

Comment 33

[Wesly Huang (EPM)]

Thanks Wayne and Seil!

Comment 34

[jingmei.zhang]

Hi Seil,

if the user just receive a call, the ringtone keeps to play after the call is connected.

could I make a modify as follows:

>// Audio_Framework: Music is mixing with ringing in FFOS2.0, after MT call
>    if (state == AudioSystem::MODE_IN_CALL) {
>        for (size_t i = 0; i < mOutputs.size(); i++) {
>            AudioOutputDescriptor *desc = mOutputs.valueAt(i);
>                setStrategyMute(STRATEGY_MEDIA, true, mOutputs.keyAt(i));
>                setStrategyMute(STRATEGY_MEDIA, false, mOutputs.keyAt(i), MUTE_TIME_MS*4,
>                    getDeviceForStrategy(STRATEGY_MEDIA, false));
>                setStrategyMute(STRATEGY_SONIFICATION, true, mOutputs.keyAt(i));
>                setStrategyMute(STRATEGY_SONIFICATION, false, mOutputs.keyAt(i), MUTE_TIME_MS*8,
>                    getDeviceForStrategy(STRATEGY_SONIFICATION, false));
>        }
>    }

Comment 35

[jingmei.zhang]

Hi Seil,

Can you help to explain why music keeps playing when the call is connected?

In my opinion,music is muted or paused when the ringtone comes and will not resume play until the call is ended.

Comment 36

[jingmei.zhang]

Hi Seil,

There might be some problems in the workaround patch in comment32.

For the delay time MUTE_TIME_MS*8,if we hang up the moment the ring tone is playing,then we could not hear music until the delay time is over.

Can you help to check the issue?

Comment 39

[Jeremiah Lee]

This issue also appears when listening to FM Radio through headphones and receiving a call.

Comment 40

[Seil Park]

(In reply to jingmei.zhang from comment #36)
> Hi Seil,
> 
> There might be some problems in the workaround patch in comment32.
> 
> For the delay time MUTE_TIME_MS*8,if we hang up the moment the ring tone is
> playing,then we could not hear music until the delay time is over.
> 
> Can you help to check the issue?

sorry, I coundn`t follow up your comment because another project. 
You are right that it has some problum after hang up the moment. but I think the temporary mute is safer better than continous mute in v2.0

In v2.2, I know the root cause is improved. 
We nomally set as MUTE_TIME_MS*2 or MUTE_TIME_MS value for android project reference.

Comment 41

[BMO Automation]

Firefox OS is not being worked on