961898 - [Sora][Clock][Accessory] Sound is just from headset side when alarm coming.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Vendcom, defect, P1)

Description

[sync-1]

build ID: 20140105004001
 
 DEFECT DESCRIPTION:
  Sound is just from headset side when alarm coming during headset mode.
 
  REPRODUCING PROCEDURES:
  1. Plug in headset;
  2. Enter "Clock"->"Alarm";
  3. Create a new alarm;
  4. Waiting for coming.
 
  EXPECTED BEHAVIOUR:
  Sound shoule be from handset and headset.
 
  CONTACT:021-61460666-7035.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

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

looks like a regression issue.Cannot reproduce on Buri 1.1 device. In Buri 1.1 device, the alarm ringtone will come out from both headset and the phone speaker.

Dear Dylan, could you help to check this one?

Comment 2

[Dylan Oliver [:doliver]]

This is more likely an AudioChannel issue rather than anything specific to Clock. It might be an intentional change. Marco, can you comment on this one?

Comment 3

[Marco Chen [:mchen]]

What gaia/gecko should make sure is alarm need to use "alarm" channel type.
Then the audio HAL which is outside the gecko will trigger this routing setting when it find this steam is a alarm type.

Hi Vance,

Do you use the same base image and device but just different Gecko/Gaia versions (1.1 and 1.3)to do test?

Comment 4

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

> 
> Hi Vance,
> 
> Do you use the same base image and device but just different Gecko/Gaia
> versions (1.1 and 1.3)to do test?
Actually since my Buri just bricked this morning, I use Peak to verify, in 1.2 build the alarm sounds can come out both from headset and speaker, however once I flash to 1.3, the sound can only come out from headset.

Vance

Comment 5

[Preeti Raghunath(:Preeti)]

1.3+ for regression

Comment 6

[Dylan Oliver [:doliver]]

(In reply to Marco Chen [:mchen] from comment #3)
> What gaia/gecko should make sure is alarm need to use "alarm" channel type.

Marcus, can you verify that Clock is using the 'alarm' channel?

Comment 7

[Marcus Cavanaugh [:mcav]]

Yes, it's using the alarm channel:

https://github.com/mozilla-b2g/gaia/blob/ef8bb31b462f364b57432a0724c78034d3f4f303/apps/clock/js/onring.js#L162

Comment 8

[Guoqiang.CHEN]

Dear Sirs,

The incoming call should also play both in headset and speaker.

Comment 9

[Dylan Oliver [:doliver]]

(In reply to Guoqiang.CHEN from comment #8)
> Dear Sirs,
> 
> The incoming call should also play both in headset and speaker.

Please make sure you file a different bug against the Dialer or AudioChannel component for that behavior if it is not working as expected.

Comment 10

[Joe Cheng [:jcheng] (please needinfo)]

hi Marco, can someone from the team look at this? Thanks

Comment 11

[sync-1]

https://bugzilla.mozilla.org/show_bug.cgi?id=963995

Comment 12

[Marco Chen [:mchen]]

Hi all,

Thanks for all your verification from each domain.

Hi Star,

Please help to check whether we transferred corresponding channel into OpenSL ES layer.
That is the boundary we can make sure it is Gecko or backend issue.

Comment 13

[Marco Chen [:mchen]]

I tested this on unagi (Gonk-ICS) with master and V1.3 branch,
and both of alarm and ringer will output to headset and speaker.

Star will update test result on hamachi too.

Comment 14

[Jason Smith [:jsmith]]

(In reply to Marco Chen [:mchen] from comment #13)
> I tested this on unagi (Gonk-ICS) with master and V1.3 branch,
> and both of alarm and ringer will output to headset and speaker.
> 
> Star will update test result on hamachi too.

Switching to qawanted then to check if this reproduces on 1.3.

Comment 16

[Star Cheng [:scheng]]

I have tested this case on Buri/Hamachi (Gonk-ICS) with master branch and v1.3 branch. Alarm and Ringer  audio streams were routed to headset and speaker. 

The audio stream will be routed to which devices is decided in AudioPolicy HAL layer instead of Gecko layer. We need the AudioPolicy HAL layer information to explain this scenario.

Comment 17

[Marco Chen [:mchen]]

Hi Sync-1,

Could you help to check from the point of Audio HAL?
Does gecko set audio stream to correct type? (we made sure on gaia and gecko side already)

Thanks.

Comment 18

[Sarah Parsons]

Removing QA Wanted per comment 16.

Comment 19

[Sandip Kamat]

PM reviewed - Stays as a blocker.

Comment 20

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 21

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

TCL is still in the Chinese New Year holidays, will ask TCL to check the Audio HAL when they back from holidays on Jan/10.

Comment 22

[Preeti Raghunath(:Preeti)]

Please confirm if this is a POVB

Comment 23

[Chris Lee [:clee]]

Can we move this as a blocker given it looks to be POVB?

Comment 24

[Jason Smith [:jsmith]]

(In reply to Chris Lee [:clee] from comment #23)
> Can we move this as a blocker given it looks to be POVB?

I'd feel better if we wait to get explicit confirmation from TCL that this is a vendor bug before we remove the blocking flag.

Comment 25

[buri.blff]

Attachment: audio.txt

log when alarm coming.

Comment 26

[buri.blff]

We have resolved this issue.It is bsp issue.You can close this bug.

Comment 27

[John Hammink]

This issue appears fixed on latest version:

Gaia      d2f6df89763407f08dcd036369c40f95025aeead
Gecko     4db8ef0c8cd27feed76b63016bfb17915e655554
BuildID   20140213013207
Version   28.0
ro.build.version.incremental=230
ro.build.date=Thu Feb 13 01:11:46 CST 2014