1083723 - [music][playback] Pops observed during music playback seek for specific clips

Status: RESOLVED WONTFIX

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

Description

[vasanth]

[Blocking Requested - why for this release]:

While doing random seek operations for specific clips, we can hear pops.
This happens for non offloaded clips (not mp3/aac)

We can share clips separately to the owner of this bug once assigned.

Comment 1

[bhavana bajaj [:bajaj]]

(In reply to vasanth from comment #0)
> [Blocking Requested - why for this release]:
> 
> While doing random seek operations for specific clips, we can hear pops.
> This happens for non offloaded clips (not mp3/aac)
> 
> We can share clips separately to the owner of this bug once assigned.

Can you please share the clips with me/Hema and I can start with QA trying to reproduce the issue here ?

Comment 2

[Hema Koka [:hema]]

No-Jun, 

I have sent you the test file via email, please check if you can reproduce this on Flame 2.1

Thanks
Hema

Comment 3

[No-Jun Park [:njpark]]

When doing seek, I hear a split-second pause and a small static in 2.1 build as well.

Version Info:
Gaia-Rev        1ea74943cfe525c76a074ca1d7de8e51a70f6b98
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/2befa902ff5c
Build-ID        20141017001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141017.050039
FW-Date         Fri Oct 17 05:00:50 EDT 2014
Bootloader      L1TC00011840

Comment 4

[No-Jun Park [:njpark]]

This is also reproducible in 2.0
Gaia-Rev        9c7dec14e058efef81f2267b724dad0850fc07e4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c17df9fe087d
Build-ID        20141017000203
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141017.033433
FW-Date         Fri Oct 17 03:34:44 EDT 2014
Bootloader      L1TC00011880

Comment 5

[David Flanagan [:djf]]

Anthony,

Is this a bug that someone on your team could investigate?

Comment 6

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Hema Koka [:hema] from comment #2)
> I have sent you the test file via email, please check if you can reproduce
> this on Flame 2.1

Can you provide workable STR including a URL to an audio track?

Comment 7

[David Flanagan [:djf]]

No-Jun: could you attach the test file to the bug, or, if it is copyrighted, email it to Anthony for investigation? Specific STR would help him out, too.  This bug doesn't even seem to specify what kind of music file is failing here, except to say it is not mp3 or aac. Are you able to reproduce with ogg and opus files, and are there non-copyrighted files (like in test_media/samples/Music) that demonstrate the bug?

If you can do that, please set needinfo for Anthony again.

Comment 8

[vasanth]

(In reply to David Flanagan [:djf] from comment #7)
> No-Jun: could you attach the test file to the bug, or, if it is copyrighted,
> email it to Anthony for investigation? Specific STR would help him out, too.
> This bug doesn't even seem to specify what kind of music file is failing
> here, except to say it is not mp3 or aac. Are you able to reproduce with ogg
> and opus files, and are there non-copyrighted files (like in
> test_media/samples/Music) that demonstrate the bug?

Please don't attach the test clip in bugzilla. It can be shared internally between needed folks via mail.

STR is play this music clip and seek at random locations. You can observe minor pops in headset.

AFAIK, this issue is this clip specific, we don't see pops with other clips.
(I guess need to be debugged w.r.t this clip)

Comment 9

[No-Jun Park [:njpark]]

I emailed the music file to Anthony just now.

STR:
copy the above audio file to the sd card (I enabled USB storage option)
Restart the phone, open Music app, select the music file and play
while playing, move the slider so it plays in different time position.

Actual:
When it starts to play after seek operation, there is a small pop sound each time.

Comment 10

[David Flanagan [:djf]]

Jim, do you have anything to add here?

Comment 11

[Jim Porter (:squib)]

Well, it might help if we used the fastseek API...

Comment 12

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Jim Porter (:squib) from comment #11)
> Well, it might help if we used the fastseek API...

The fastseek API makes videos seek to a keyframe and therefore avoid a bunch of unnecessary decoding.

(In reply to No-Jun Park [:njpark] from comment #9)
> I emailed the music file to Anthony just now.

It is an AAC file in MP4 file. Hmm...

> Actual:
> When it starts to play after seek operation, there is a small pop sound each
> time.

On desktop it makes a noise (it doesn't fade in/out) but there is an additional noise on Firefox OS that doesn't exist on desktop.

Blake - do you have time to look into this?

Comment 13

[Blake Wu [:bwu][:blakewu]]

Hi ajones, 
Could you email me the file? I can take a look. 
Maybe this noise is caused by PlaySilence().

Comment 14

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Blake Wu [:bwu][:blakewu] from comment #13)
> Maybe this noise is caused by PlaySilence()

Most likely from what I'm hearing.

Comment 15

[Dietrich Ayala (:dietrich)]

QA can you do a 1.4 branch check to see if this is a regression?

User impact seems low - No Jun said it's super quiet, so triage is not sure it's worth blocking on.

What's the use-case for AAC inside MP4 container? Is that common?

Comment 16

[Hema Koka [:hema]]

(In reply to Dietrich Ayala (:dietrich) from comment #15)
> QA can you do a 1.4 branch check to see if this is a regression?
> 
> User impact seems low - No Jun said it's super quiet, so triage is not sure
> it's worth blocking on.
> 
> What's the use-case for AAC inside MP4 container? Is that common?

Vasanth/Inder, do you have input on how common this case is (btw, this issue is also reproducible on 2.0). The small pop sound seems to be a low-impact issue and does not deem to make this bug a release blocker at this stage of the 2.1 release.

Thanks
Hema

Comment 17

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

(In reply to Dietrich Ayala (:dietrich) from comment #15)
> QA can you do a 1.4 branch check to see if this is a regression?

QA will need the file in order to reproduce the bug. Please email the file to [e-mail]

Comment 18

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I reproduced the issue on 2.0. I think it is a silence more than a pop. Onomatopoeia isn't always the best way to communicate a sound.

Comment 19

[Dave Hylands [:dhylands]]

If its silence, then it doesn't sound like a blocker.

It its a pop, then more investigation might be warranted.

Comment 20

[Blake Wu [:bwu][:blakewu]]

Attachment: dump_pcm.png

I did two-time seek and dumped the pcm data from AudioFlinger. 
The first seek sounds ok but the second one is not which we can see there is some data in between.  
In the beginning, the same problem seems to happen as well.

Comment 21

[Blake Wu [:bwu][:blakewu]]

This problem can be found with the files, AAC_8khz_Mono_5.aac and AAC_12khz_Mono_5.aac, from http://download.wavetlan.com/SVV/Media/HTTP/http-aac.htm. It is required to modify the file extension to be .mp4 and push to phone. However, it is not easily found by hearing, so I checked it with the dumped pcm file. 

With Mis_Test_5 - MP4_ACC-LC_Mono_44100Hz - Eric_Clapton-Wonderful_Tonight.MP4 on the same website, this problem *cannot* be seen.  

Probably this problem is related to resample.

Comment 22

[Blake Wu [:bwu][:blakewu]]

Attachment: dump_pcm_aac_8k.out

This pcm is dumped from playing AAC_8khz_Mono_5.mp4 while I seeked to 8 sec, 19 sec, and 30 sec. Some strange data can be seen around 19 sec and 30 sec which caused pops.

Comment 23

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

I was able to reproduce this issue on the v165 1.4 Flame KK base image.

Comment 24

[vasanth]

(In reply to Hema Koka [:hema] from comment #16)
> Vasanth/Inder, do you have input on how common this case is (btw, this issue
> is also reproducible on 2.0). The small pop sound seems to be a low-impact
> issue and does not deem to make this bug a release blocker at this stage of
> the 2.1 release.

We see this issue only with some clips and we are not sure it is a common case.
Even though its a small pop, issue appears consistently during seek.
From analysis, if its found to be not a common case, we can remove blocker?

Comment 25

[Jim Porter (:squib)]

(In reply to vasanth from comment #24)
> We see this issue only with some clips and we are not sure it is a common
> case.
> Even though its a small pop, issue appears consistently during seek.
> From analysis, if its found to be not a common case, we can remove blocker?

This seems reasonable to me. I haven't heard pops during seeking on any of my personal music, but then I don't have any mp4 files.

Comment 26

[Hema Koka [:hema]]

Based on comment 24, moving out of blocking nom

Comment 27

[Inder]

Hema -- have we determined for sure that it's not a common case with mp4 files? We have seen in the past that OEMs have come back looking for a fix during their testing if such issues seem to be happening with multiple files.

Comment 28

[Hema Koka [:hema]]

Inder, I have requested No-jun to test with a bunch of test mp4 files to make sure it is not happening with all mp4 files. 

Thanks
hema

Comment 29

[No-Jun Park [:njpark]]

I tried various files from the site mentioned in Comment 21, and while i could also hear the small pop in AAC_8hz_Mono_5.aac and AAC_8khz_Mono_5.aac, it is again very faint.  With other files, I could not hear this pop sound after the seek operation.

Comment 30

[Sotaro Ikeda [:sotaro]]

On some mp3 file, similar problem is reported at Bug 1052206 comment 120.

Comment 31

[Jim Porter (:squib)]

Could QA take a look at this, preferably on a couple different devices? There have been a lot of issues like this, and I'd like to narrow them down to the list of what's still happening. Then we can try to get them fixed. :)

Comment 32

[Autumn.Qiu(Leave from Mozilla)]

Hi Jim, 
1.This bug can't be reproduced on latest build of Flame KK v2.6/2.5/2.2 512mb, by the STR in comment 9.
The files I used are AAC_8khz_Mono_5.aac and AAC_12khz_Mono_5.aac, according to comment 21, I also modified the file extension to .mp4.
Actual results: When user moves slider to different time position, there is no minor pops in headset.
See attachment: Flame_KK_v2.6_Una.3gp
Reproduce rate: 9/9

2.But when I push AAC_8khz_Mono_5.mp4 or AAC_12khz_Mono_5.mp4 to Aries KK v2.6/2.5, open Music app and try to play them, there is no voice, progress bar does not move and time displays as 0:00.
Please see Bug 1223327

Device: Flame KK v2.6 512MB(Master)
Build ID               20151109150204
Gaia Revision          23cab7ea0fcecab7689d340baf604e024e88f9a3
Gaia Date              2015-11-09 06:13:17
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e1ef2be156de1dad31bb4189a51b178b12b23340
Gecko Version          45.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151109.182508
Firmware Date          Mon Nov  9 18:25:22 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK v2.5 512MB 
Build ID               20151109004552
Gaia Revision          cf646c52bb947af28329b0a100df91d1b1f2a907
Gaia Date              2015-11-09 02:55:50
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/4eafef5b80f8985c94c4a067f130d37513e1a581
Gecko Version          44.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151109.041411
Firmware Date          Mon Nov  9 04:14:26 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK v2.2 512MB 
Build ID               20151109032503
Gaia Revision          885647d92208fb67574ced44004ab2f29d23cb45
Gaia Date              2015-10-07 13:05:24
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e6ea91190b53
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151109.065527
Firmware Date          Mon Nov  9 06:55:39 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Comment 33

[Autumn.Qiu(Leave from Mozilla)]

Attachment: Flame_KK_v2.6_Una.3gp

Comment 34

[Autumn.Qiu(Leave from Mozilla)]

Sorry, modify comment #32 "Reproduce rate: 9/9" to "Reproduce rate: 0/9".

Comment 35

[BMO Automation]

Firefox OS is not being worked on