1090657 - [Loop] Audio playback is muted during FirefoxHello VT call

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Loop, defect)

Description

[Jay]

[Blocking Requested - why for this release]:

Pre-Conditions:
1. Insert SD card with supported audio clips

Steps to reproduce:
1. Make a VT call from FirefoxHello app from DUT1
2. Receive the call at DUT2 and observe audio of VT call is routing to speaker
3. During VT call select Home screen
4. Now launch Music app and start audio playback

Issue:
- unable to hear audio playback from DUT. 


Expected behavior:
Audio playback should be routed to DUT speaker. The same test case works with phone app.

Comment 1

[Jay]

Can you help to check this?

Comment 2

[José Antonio Olivera Ortega [:jaoo]]

I'll comment here with Maria's permission. Leave a ni? request at me.

Comment 3

[José Antonio Olivera Ortega [:jaoo]]

I gave a try and I saw the same behavior between the callscreen app (GSM/CDMA calls) and the Loop client app (WebRTC call) which is music plays. Anyway IMHO this is not a common use case, isn't it?. I tested this on FxOS 2.0/Loop 1.1 which is what we are going to ship AFAIK. What's your environment for your test?

Comment 4

[Jay]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #3)
> I gave a try and I saw the same behavior between the callscreen app
> (GSM/CDMA calls) and the Loop client app (WebRTC call) which is music plays.
> Anyway IMHO this is not a common use case, isn't it?. I tested this on FxOS
> 2.0/Loop 1.1 which is what we are going to ship AFAIK. What's your
> environment for your test?

I tested this on v2.1

Comment 5

[bhavana bajaj [:bajaj]]

shell,

can you help drive this one. Not sure if this is a loop issue or needs a platform fix on our side.

Comment 6

[Maria Angeles Oteo (:oteo)]

I am testing the Loop Mobile application over 2.0 FxOS and is working fine, I can hear the audio playback in the same way that GSM call behaves when it interacts with Music app.

So if in 2.1 FxOS version the audio playback from DUT is not heard (I have not tested it in 2.1) is not a Loop issue but a platform one.

Comment 7

[Inder]

Considering that it's a regression from 2.0 we should get this fixed in 2.1

Comment 8

[:shell escalante]

HI, not sure who is best to ask - so asking both Media and Devices teams.  Steven and/or Marco - do you have any insight into what could have caused the regression or who would be good to investigate?

Comment 9

[StevenLee[:slee]]

Randy,

Can you help this bug? thanks.

Comment 10

[Marco Chen [:mchen]]

Steven's team will handle this. Thanks Steven and Randy.

Comment 11

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

I had test on:
Gaia-Rev        9658b93b412bdcc0f953d668e8c8e68318c99fb8
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/76880403db44
Build-ID        20141105161202
Version         34.0
It works well under those condition and MUSIC sound can be hear on speaker or receiver, too.
1. Music volume should large than 0.
2. Music should be the front-ground (If music fail into background it would paused by audiochannel.)

Comment 12

[bhavana bajaj [:bajaj]]

(In reply to Randy Lin [:rlin] from comment #11)
> I had test on:
> Gaia-Rev        9658b93b412bdcc0f953d668e8c8e68318c99fb8
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/76880403db44
> Build-ID        20141105161202
> Version         34.0
> It works well under those condition and MUSIC sound can be hear on speaker
> or receiver, too.
> 1. Music volume should large than 0.
> 2. Music should be the front-ground (If music fail into background it would
> paused by audiochannel.)

When CAF/I triaged this we were not sure if you used the exact STR in description, so adding qawanted here for help testing this on 2.0/2.1

Comment 13

[Jay]

(In reply to Randy Lin [:rlin] from comment #11)
> I had test on:
> Gaia-Rev        9658b93b412bdcc0f953d668e8c8e68318c99fb8
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/76880403db44
> Build-ID        20141105161202
> Version         34.0
> It works well under those condition and MUSIC sound can be hear on speaker
> or receiver, too.
> 1. Music volume should large than 0.
> 2. Music should be the front-ground (If music fail into background it would
> paused by audiochannel.)

Actually, after increasing the music volume by first playing the music app and then start the webRTC call, I am able to hear the music during webRTC call.

However, I couldn't change the volume of the music during the webRTC call. So, I think the problem is that the music volume is 0 by default and since volume doesn't work for music during webRTC call, audio becomes mute.

So, we need to find out why the volume was not applied to music stream while webRTC call was in progress.
By the way, I see the same behavior for v2.0 and v2.1

Comment 14

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue only occurs if media volume is turned to 0 (which is not default on any build I checked, it was always max by default) and then the user cannot change volumes while in the Loop call without going to the settings app and the sound section because call audio has priority over app audio.  This is the same functionality as Dialer app which leads me to believe this might not actually be considered a bug.  Removing the regression-window wanted tag for now, please feel free to re-add it or the qawanted tag if you feel this is a bug.

Environmental Variables:
Device: Flame 2.1
BuildID: 20141106071119
Gaia: aa63911ae979ed1e3eab2ba23a6e7d6a59085854
Gecko: 780af6b71bf2
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 15

[Joshua Mitchell (Inactive)]

Jayme makes a good point - this seems to be functioning as design - 

NI to Loop owner to weigh in -  is this valid / invalid?

Comment 16

[Jay]

(In reply to Jayme Mercado [:JMercado] from comment #14)
> This issue only occurs if media volume is turned to 0 (which is not default
> on any build I checked, it was always max by default) and then the user
> cannot change volumes while in the Loop call without going to the settings
> app and the sound section because call audio has priority over app audio. 
> This is the same functionality as Dialer app which leads me to believe this
> might not actually be considered a bug.  Removing the regression-window
> wanted tag for now, please feel free to re-add it or the qawanted tag if you
> feel this is a bug.
> 
> Environmental Variables:
> Device: Flame 2.1
> BuildID: 20141106071119
> Gaia: aa63911ae979ed1e3eab2ba23a6e7d6a59085854
> Gecko: 780af6b71bf2
> Version: 34.0 (2.1) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

You are right. Dialer app behaves the same so user just needs to go through setting to adjust the music volume in case it is muted.

Comment 17

[Jay]

Remove from the CAF meta blocking list as it is not an issue.

Comment 18

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

It's by design, Switch to invalid.