Closed Bug 1148049 Opened 9 years ago Closed 8 years ago

[Music] Playback stutter when listening through Bluetooth device when moving between tracks or scrubbing

Categories

(Core :: Audio/Video: Playback, defect, P2)

Product:
Core
Component:
Audio/Video: Playback
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1052206
Project Flags:
blocking-b2g 2.5+
Tracking Flags:
Tracking Status
b2g-v2.0 --- ?
b2g-v2.1 --- ?
b2g-v2.2 --- affected
b2g-v2.5 --- affected
b2g-master --- affected

People

(Reporter: onelson, Assigned: bechen)

References

(
URL
)

Details

(Whiteboard: [3.0-Daily-Testing])

Attachments

(5 files, 1 obsolete file)

Log : Can't use offload player, fails on getOutput()
2.06 KB, text/plain
Details
Dump-Audio-PCM-from-AudioFlinger.patch
3.14 KB, patch
Details | Diff | Splinter Review
silence_inside.png
34.44 KB, image/png
Details
fix silence frames.
61 bytes, text/x-github-pull-request
Details | Review
SONG_0002.mp3
594.48 KB, audio/mpeg
Details 
Description:
When a user listens to music on their phone through a bluetooth device, they will observe that anytime the audio "cuts" out to transition songs (between skipping to a new song, or scrubbing through the duration of a current song), they will observe that the playback will stutter initially. This stutter is only observed when listening through a bluetooth device, and not apparent when the user is listening through plugged in headphones or the phone speaker.


Repro Steps:
1) Update a Flame to 20150326010205
2) Connect a bluetooth speaker/headset through Settings
3) Once audio is routed through bluetooth device, open Music app
4) Start a playlist in Music
5) Skip to the next track, observing audio
6) Scrub through to random points in song, observing audio

Actual:
Audio stutters between playbacks on skip/scrub while listening through a bluetooth device

Expected:
Audio is seamless between playbacks on skip/scrub


Environmental Variables:
-------------------------------------
Device: Flame 3.0
Build ID: 20150326010205
Gaia: 8dc256a2de273be3abfa2cb2103d872d677834f7
Gecko: 37d3dcbf23a9
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0
-------------------------------------

Device: Flame 2.2
BuildID: 20150326002504
Gaia: e59ac067a1d22b7a72cbebc892ec652723f2a557
Gecko: 04b4b9d1faae
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
--------------------------------------------------

Blocked from testing on 2.1 and 2.0 for flame devices as Music app closes when attempting to open songs

Device: Flame 2.1
BuildID: 20150326001202
Gaia: 6f39e4e876152de1dcdcc0e7656197f22f105e4b
Gecko: e00ae73d67a2
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20150326000204
Gaia: 896803174633fc6acd3fd105f81c349b8e9b9633
Gecko: 543c2325d667
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
--------------------------------------------------


Repro frequency: 10/10
See attached: 
video- https://youtu.be/GbLqUFfhXMI
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing]
QAWanted to check what happens on base image only.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
(In reply to Peter Bylenga [:PBylenga] from comment #1)
> QAWanted to check what happens on base image only.

This issue reproduces on v18D-1 base image only. The music stutters when skipping tracks or scrubbing using the progress bar.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Music app dose not involve in sending audio to bluetooth devices, maybe it's better to put this in the bluetooth component to catch the developer's attention.
Component: Gaia::Music → Bluetooth
Nominate for v3.0 work tracking, the effect is slightly noticeable.
blocking-b2g: --- → 3.0?
ni? Shawn to take a quick look.
Flags: needinfo?(shuang)
I checked the youtube video, and it looks like an old bug (bug 937611) i reported before. And bug937611 has been marked as a duplicate of bug 940177. It has been resolved by moving bufferqueue_callback at the beginning of opensl_stream_start. 

:alwu would you please confirm again bug 940177 can fix the problem? That used to fix the bug when we're releasing fxos v2.0.
Flags: needinfo?(shuang) → needinfo?(alwu)
Keep ni for tracking, I will check it later.
This issue seems not related with bug940177, because its modification still exists.
I observed some strange points, but I don't know whether this is the reason of this issue.

---

There are two different mechanisms for media playback, the AudioOffloadPlayer for only audio, or the AudioSink for video. The AudioOffloadPlayer has lower latency, so it is proper to be used on audio playback. 

I found that when we use the bluetooth device, the audio playback would be changed to the AudioSink. Maybe it's the root cause, and I'm still looking for more details.
Attached file Log : Can't use offload player (obsolete) — 
From the log, we got error, "NO_INIT", from creating an new Android::AudioTrack.
No idea why we would fail here.
Hi, Shawn,
Is it possible that BT doesn't handle the audio data well?

Because I use the speaker/wired headset to listen the streaming audio, which is also use the AudioSink. That means the differences of the playback mechanism might not the reason of this issue.
Thanks!
Flags: needinfo?(alwu) → needinfo?(shuang)
(In reply to Alastor Wu [:alwu] from comment #11)
> Hi, Shawn,
> Is it possible that BT doesn't handle the audio data well?
> 
> Because I use the speaker/wired headset to listen the streaming audio, which
> is also use the AudioSink. That means the differences of the playback
> mechanism might not the reason of this issue.
> Thanks!

Sorry for late reply here. I think we need to analyze the delay between AudioFlinger and a2dp audio hw.
Can you provide any method to dump PCM data from AudioFlinger?
Flags: needinfo?(shuang) → needinfo?(alwu)
Sorry for my late reply. Here is the tutorial of dumping PCM data (author is Star).
https://drive.google.com/file/d/0B8z53fPg4O7NYzFWNFJoaWpyUGs/view?usp=sharing
Flags: needinfo?(alwu)
ni? for taking a dump here.
Flags: needinfo?(shuang)
blocking-b2g: 2.5? → 2.5+
Shawn will help check this bug after 2.2R MAP completes. Set owner first.
Assignee: nobody → shuang
P2 for 2.5
Priority: -- → P2
Ben/Al, 

Can you please take a look at this bug? There is not much progress on this for a month. 

Thanks
Flags: needinfo?(btian)
Flags: needinfo?(alwu)
(In reply to Mahendra Potharaju [:mahe] from comment #17)
> Ben/Al, 
> 
> Can you please take a look at this bug? There is not much progress on this
> for a month. 
> 
> Thanks

Sorry, i'm working on v2.2r features, so this bug doesn't get much attention. I will try to give a meaningful update before 10/2.
Thanks Shawn
(In reply to Alastor Wu [:alwu][OOO from 10/3-10/11] from comment #13)
> Sorry for my late reply. Here is the tutorial of dumping PCM data (author is
> Star).
> https://drive.google.com/file/d/0B8z53fPg4O7NYzFWNFJoaWpyUGs/view?usp=sharing

Hi Alastor,
I'm not sure which file I can add audio dump because I cannot find the file path under 'aries-l/B2G/hardware/qcom/media'.

As you provided the way to dump in:
<CodeBaseDir>/hardware/qcom/media/audio/msm7627a/AudioHardware.cpp

Can you just directly provide me .so file to dump PCM data? So we can clarify it further. Otherwise, we still cannot find the problem is.
Flags: needinfo?(shuang)
Hi Alastor,
I also tried to find 
flame-kk/B2G/hardware/qcom/media, and I don't see "AudioHardware.cpp".
Hi Alastor,
I don't want to spend time back-and-forth on compiling AudioHardware that I cannot easily find as your side mentioned I need to patch AudioHardware.cpp, so I probably need your assistance here.
Can you simply dump the PCM data from your side and upload to this bug. So we can ideally check that extra playback shutter came from audio or that caused by Bluetooth. If we cannot hear playback shutter from RAW PCM data, I will figure out from bluetooth side.
Hi Blake,
If alwu is busy, can you help?
Flags: needinfo?(bwu)
Hi, Shawn,
Blake have already dumped the pcm data from Gecko::AudioStream before [1].
From his comment, the audio data seems no problem.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1166758#c40
Flags: needinfo?(alwu)
(In reply to Alastor Wu [:alwu][OOO from 10/3-10/11] from comment #24)
> Hi, Shawn,
> Blake have already dumped the pcm data from Gecko::AudioStream before [1].
> From his comment, the audio data seems no problem.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1166758#c40

Hi Alastor,
Thanks for the comments.
But this is not the same problem.
Here the case is to move progress when using music player and user can observe the last audio frame not smoothly move to the next audio frame (that user taps to the new timestamp). If this is not the same case, can we make this conclusion that audio data seems no problem?
Also, there is no much difference in A2DP playback between b2g and Android, the AudioFlinger and A2DP Audio hardware node (external/bluetooth/bluedroid/audio_a2dp_hw) should be the same. Gecko Bluetooth actually don't handle this part, unless we suffer some system-wide scheduling issue.

If you don't mind I still want to examine PCM data from Audio flinger or audio hardware. And of course dump from AudioStream might be helpful for clarifying a bit.
If you dump from AudioStream, i'm afraid this cannot clarify all the other layers including AudioHardware (gonk) and Android HAL library (AudioFlinger).
Hi Alastor,
Another question about this issue.
When you move music player progress bar (scrub through to random points in song), what's the behavior for AudioTrack?

If I recall correctly, there are some differences between Android and b2g how we use AudioTrack. When you fast-forward to the certain timestamp (or point) in song, AudioTrack will be deleted and recreate again.
I think we might have some action plans:
1. Dump PCM data from audiofilnger or audiohardware
2. Analyze what happened when you do fast-forward. Note if you don't do this action, we won't hit audio shutter. I'm still wondering what happened when you recreates AudioTrack as I remember doing fast-forward, AudioTrack recreates.
Dump Audio PCM from AudioFlinger.
Flags: needinfo?(bwu)
(In reply to Shawn Huang [:shawnjohnjr] from comment #28)
> I think we might have some action plans:
> 1. Dump PCM data from audiofilnger or audiohardware
> 2. Analyze what happened when you do fast-forward. Note if you don't do this
> action, we won't hit audio shutter. I'm still wondering what happened when
> you recreates AudioTrack as I remember doing fast-forward, AudioTrack
> recreates.
Sorry for the late response! 
Agree with you for action plans. I am not sure if the possible root cause is related to AudioTrack or not. But at least based on dumped PCM data we can know if it is BT bug or not.
Flags: needinfo?(alwu)
After checking the dumped PCM, I confirmed this is not a BT bug. 
Change the component to be audio/video playback.
Component: Bluetooth → Audio/Video: Playback
Product: Firefox OS → Core
Assignee: shuang → nobody
Blocks: TV_Gecko_P2
Assignee: nobody → bwu
Attached image silence_inside.png — 
From the dumped PCM data from AudioSystem, it looks like some silence data are inserted right after seeking.
(In reply to Blake Wu [:bwu][:blakewu] from comment #32)
> Created attachment 8674180 [details]
> silence_inside.png
> 
> From the dumped PCM data from AudioSystem, it looks like some silence data
> are inserted right after seeking.
This inserted silence data results from underrun situation [1]. 
Continue to check why we easily hit underrun situation in BT connected case. 

[1]https://dxr.mozilla.org/mozilla-central/source/dom/media/AudioStream.cpp?case=true&from=AudioStream.cpp#744
After enlarging the size of mbuffer[1] in AudioSystem, this problem still occurs. 
So, audio decoded data could be too low. 
Need to check if we always have enough audio decoded data in the queue for consuming.  

[1] https://dxr.mozilla.org/mozilla-central/source/dom/media/AudioStream.cpp?case=true&from=AudioStream.cpp#360
After discussing with Benjamin offline, he will help further investigate this bug. 
Thanks Benjamin!
Assignee: bwu → bechen
I/Gecko   (21439): dis 0 time 0 duration 14126 frames 623 //abnormal
I/Gecko   (21439): OnAudioDecoded [0,14126] disc=1
I/Gecko   (21439): dis 0 time 26122 duration 26122 frames 1152 //normal
...
I/Gecko   (21439): missingFrames.value() 528

==
The log shows that the audio sample with discontinuity flag comes from gonk is corrupt.
Assignee: bechen → bwu
See line 309~325
http://androidxref.com/6.0.0_r1/xref/frameworks/av/media/libstagefright/codecs/mp3dec/SoftMP3.cpp#309

For example the first audio frame:
The comment says the mp3 decode delay is 529 frames, so it trim some frames. But the line 324 325 still assign the timestamp to 0. That makes the MDSM receive a audio chunk with 623 (1152-529) frames with time stamp 0. Then the second audio chunk start from frame 1152 position cause the silence.
Assignee: bwu → bechen
See Also: → 1112438
Attached file fix silence frames. — 

        Attachment #8681830 -
        Flags: review?(sotaro.ikeda.g)

    
    

    
  
(In reply to Benjamin Chen [:bechen] from comment #38)
> Created attachment 8681830 [details] [review]
> fix silence frames.
Since the libstagefright codes on some device are not open and cannot be modified, is it possible that we can modify our gecko codes to fix this bug?

    
    

    
  
The problem seems to be caused by same cause to Bug 1052206.
See Also:  → 1052206

    
    

    
  
(In reply to Blake Wu [:bwu][:blakewu] from comment #39)
> (In reply to Benjamin Chen [:bechen] from comment #38)
> > Created attachment 8681830 [details] [review]
> > fix silence frames.
> Since the libstagefright codes on some device are not open and cannot be
> modified, is it possible that we can modify our gecko codes to fix this bug?

I also think that it seems better to fix in gecko side if the playback uses MediaFormatReader. If it uses MediaOmxReader for playback, it seems better to fix it in OMXCodec like Bug 1052206.

Bug 1052206 was problem of MediaOmxReader and OMXCodec. OMXCodec has a capability of cut EncoderDelay and EncoderPadding by using SkipCutBuffer. But its time stamp was not correct when SkipCutBuffer cut the MediaBuffer. Bug 1052206 fixed timestamp of MediaBuffer. OMXCodec got EncoderDelay and EncoderPadding time from MediaExtractor.

Important point is that EncoderDelay and EncoderPadding could exist in mp3 and mp4. It is not a mp3 only problem and their time could be different depend on the media file.

If MediaFormatReader is used, gecko need to get EncoderDelay and EncoderPadding from geco's mp3 and mp4 pareser. And GonkAudioDecoderManager could do same thing to the SkipCutBuffer based on the EncoderDelay and EncoderPadding.

    
    

    
  
bechen, how do you think about comment 41?
Flags: needinfo?(bechen)

    
    

    
  
stagefright cut EncoderDelay and EncoderPadding at OMXCodec and ACodec level. They got EncoderDelay and EncoderPadding from stagefright extractor and cut them by using SkipCutBuffer. But SkipCutBuffer does not update timestamp correctly for gecko, since stagefright does not need such precise timestamp to playback audio.

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #40)
> The problem seems to be caused by same cause to Bug 1052206.

In fact, I only fix the silence frame's position(timestamp)for decoderDelay. attachment 8674180 [details].
On flame device, the tick noise still exist every time when I do a seek. It seems another story.

(In reply to Blake Wu [:bwu][:blakewu] from comment #39)
> Since the libstagefright codes on some device are not open and cannot be
> modified, is it possible that we can modify our gecko codes to fix this bug?

No, I don't think we can fix in gecko because the timestamp and the number of frames were decided in SoftMP3.cpp. In gecko we can only inject silence frames if there is a gap.

(In reply to Sotaro Ikeda [:sotaro] from comment #43)
> stagefright cut EncoderDelay and EncoderPadding at OMXCodec and ACodec
> level. They got EncoderDelay and EncoderPadding from stagefright extractor
> and cut them by using SkipCutBuffer. But SkipCutBuffer does not update
> timestamp correctly for gecko, since stagefright does not need such precise
> timestamp to playback audio.

Since there are EncoderDelay, EncoderPadding, DecoderDelay for an mp3 file, the SkipCutBuffer can only handle the EncoderDelay and EncoderPadding, not DecoderDelay.
http://yirkha.foobar2000.org/fimg/mp3-gapless.png
(In fact, I even don't think the SoftMP3 handle the decoderDelay correct...)
Flags: needinfo?(bechen)

    
    

    
  
(In reply to Benjamin Chen [:bechen] from comment #44)
> (In reply to Sotaro Ikeda [:sotaro] from comment #40)
> > The problem seems to be caused by same cause to Bug 1052206.
> 
> In fact, I only fix the silence frame's position(timestamp)for decoderDelay.
> attachment 8674180 [details].
> On flame device, the tick noise still exist every time when I do a seek. It
> seems another story.
> 
> (In reply to Blake Wu [:bwu][:blakewu] from comment #39)
> > Since the libstagefright codes on some device are not open and cannot be
> > modified, is it possible that we can modify our gecko codes to fix this bug?
> 
> No, I don't think we can fix in gecko because the timestamp and the number
> of frames were decided in SoftMP3.cpp. In gecko we can only inject silence
> frames if there is a gap.

Hmm, I talked about a bit different problem. This bug is about a wrong timestamp of first frame of SoftMP3. The decoder removes top 529 samples, but it does not update the timestamp.

But attachment 8681830 [details] [review] seems also not good fix, because when we repeat the music, it add unnecessary no sound time period. How do you think about it?
Flags: needinfo?(bechen)

    
    

    
  
(In reply to Benjamin Chen [:bechen] from comment #44)
> Since there are EncoderDelay, EncoderPadding, DecoderDelay for an mp3 file,
> the SkipCutBuffer can only handle the EncoderDelay and EncoderPadding, not
> DecoderDelay.
> http://yirkha.foobar2000.org/fimg/mp3-gapless.png
> (In fact, I even don't think the SoftMP3 handle the decoderDelay correct...)

Is there a valid way to detect decoder delay? It is not included as metadata of mp3 file. That seems the reason why stagefright does not handle it.

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #46)
> (In reply to Benjamin Chen [:bechen] from comment #44)
> > Since there are EncoderDelay, EncoderPadding, DecoderDelay for an mp3 file,
> > the SkipCutBuffer can only handle the EncoderDelay and EncoderPadding, not
> > DecoderDelay.
> > http://yirkha.foobar2000.org/fimg/mp3-gapless.png
> > (In fact, I even don't think the SoftMP3 handle the decoderDelay correct...)
> 
> Is there a valid way to detect decoder delay? It is not included as metadata
> of mp3 file. That seems the reason why stagefright does not handle it.

Sorry, it is handled by SoftMP3 and cause this bug.

    
    

    
  
The following also might help to see Encoder delay and decoder delay
  http://mp3decoders.mp3-tech.org/decoders_lame.html

    
    

    
  
(In reply to Benjamin Chen [:bechen] from comment #44)
> 
> Since there are EncoderDelay, EncoderPadding, DecoderDelay for an mp3 file,
> the SkipCutBuffer can only handle the EncoderDelay and EncoderPadding, not
> DecoderDelay.

Is there necessity that SkipCutBuffer handle DecoderDelay? From stagefright's implementation, it seems a responsibility of omx decoder.

    
    

    
  
I confirmed that OMXCodecs of b2g v2.2 and b2g v2.5 do not have a fix of 1052206. It means that when MediaOmxReader is used for playback, there could be a case that timestamp of MediaBuffer could be wrong.
See Also: 1052206 → 
Depends on: 1052206

    
    

    
  
b2g v2.2, v2.5 and master still uses MediaOmxReader and OMXCodec for mp3 playback. Bug 1214208 disabled MediaFormatReader usage for now.

    
    

    
  
Bug 1052206 only affect to a noise that happens at a start of mp3 playback.

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #52)
> Bug 1052206 only affect to a noise that happens at a start of mp3 playback.

SoftMP3's problem(attachment 8681830 [details] [review]) also affect only to first frame. When I tested some mp3 files locally, 1st and 2nd decoded frames were removed by SkipCutBuffer. Therefore, in normal use case, the SoftMP3's problem was masked by SkipCutBuffer and it seems not affect to mp3 playback.

    
    

    
  
bwu, do you know if MediaFormatReader + PlatformDecoder combination handles EncoderDelay and EncoderPadding of mp3 and mp4? It it is not, it is better to be addressed in a different bug.
Flags: needinfo?(bwu)

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #52)
> Bug 1052206 only affect to a noise that happens at a start of mp3 playback.

In Bug 1052206, I landed fix to mozilla-b2g/platform_frameworks_av. But flame-kk build refer to caf repository and the tag does not include the fix. Therefore, the fix was not applied to flame-kk.

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #53)
> (In reply to Sotaro Ikeda [:sotaro] from comment #52)
> > Bug 1052206 only affect to a noise that happens at a start of mp3 playback.
> 
> SoftMP3's problem(attachment 8681830 [details] [review]) also affect only to first
> frame. When I tested some mp3 files locally, 1st and 2nd decoded frames were
> removed by SkipCutBuffer.

I meant decoded data of 1st and 2nd MediaBuffers  were removed by SkipCutBuffer.

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #49)
> (In reply to Benjamin Chen [:bechen] from comment #44)
> > 
> > Since there are EncoderDelay, EncoderPadding, DecoderDelay for an mp3 file,
> > the SkipCutBuffer can only handle the EncoderDelay and EncoderPadding, not
> > DecoderDelay.
> 
> Is there necessity that SkipCutBuffer handle DecoderDelay? From
> stagefright's implementation, it seems a responsibility of omx decoder.

I'm not sure about it, because when I read the SoftMP3.cpp, I think the decoderDelay should be handle by the underlying mp3 decode library(pvmp3_xxxxxxx) because the timestamp comes from the |inHeader| which should know nothing about decodeDelay (|mAnchorTimeUs = inHeader->nTimeStamp;|).
So I guess the SkipCutBuffer remove the encoderDelay and encoderPadding is ok.

          status-b2g-v2.5:
          affected → ---
Flags: needinfo?(bechen)

    
  

          status-b2g-v2.5:
          --- → affected

    
    

    
  
(In reply to Sotaro Ikeda [:sotaro] from comment #54)
> bwu, do you know if MediaFormatReader + PlatformDecoder combination handles
> EncoderDelay and EncoderPadding of mp3 and mp4? It it is not, it is better
> to be addressed in a different bug.
No. AFAIK, they are not handled yet.
Flags: needinfo?(bwu)

    
    

    
  
When revisiting bug 1052206 and finding bug 1052206 comment 49 is a good question, I don't see any answer for it. Why do we check audio timestamp to see if it is continuous or not and insert silence if it isn't?

    
    

    
  
(In reply to Blake Wu [:bwu][:blakewu] from comment #58)
> (In reply to Sotaro Ikeda [:sotaro] from comment #54)
> > bwu, do you know if MediaFormatReader + PlatformDecoder combination handles
> > EncoderDelay and EncoderPadding of mp3 and mp4? It it is not, it is better
> > to be addressed in a different bug.
> No. AFAIK, they are not handled yet.

Crated Bug 1221845.
See Also:  → 1221845

    
    

    
  
Benjamin, 
Any update?
Flags: needinfo?(bechen)

    
    

    
  
(In reply to Blake Wu [:bwu][:blakewu] from comment #61)
> Benjamin, 
> Any update?

See comment 41, and Bug 1052206, maybe we should do the same fix.
Flags: needinfo?(bechen)

    
    

    
  
Blake/Benjamin, 

Any update on this ticket? Its a P2 and blocks TV needs it as part of 2.5 release 

Thanks
Flags: needinfo?(bwu)
Flags: needinfo?(bechen)

    
    

    
  
(In reply to Mahendra Potharaju [:mahe] from comment #63)
> Blake/Benjamin, 
> 
> Any update on this ticket? Its a P2 and blocks TV needs it as part of 2.5
> release. 
After discussing with Benjamin offline today, we think the fix in bug 1052206 may be able to fix this bug as well. But we will double check it. 
Regarding being one of TV blockers, this bug should not block TV since AFAIK this root cause of this bug is in the decoding pipeline and the current decoding pipeline of our TV partner is different than ours. 

Josh, 
Can our partner see this problem on TV?
Flags: needinfo?(bwu) → needinfo?(jocheng)

    
    

    
  
Hi Cynthia, Hi Alison,
Do you mind help testing whether this can be reproduced on real TV?
Thanks!
Flags: needinfo?(jocheng)
Flags: needinfo?(ctang)
Flags: needinfo?(ashiue)

    
    

    
  
Hi Josh,
The QA team will be out of office to go on a team building tomorrow(Friday). If you don't mind, we will try to reproduce it next Monday. 

(In reply to Josh Cheng [:josh] from comment #65)
> Hi Cynthia, Hi Alison,
> Do you mind help testing whether this can be reproduced on real TV?
> Thanks!

    
    

    
  
Hi Josh, 
After disscusing with SC, this patch would not effect TV project in 2015/2016. Thank you!
Flags: needinfo?(ctang)
Flags: needinfo?(ashiue)

    
    

    
  
Update status:
flame device, use music app to play the default mp3.

Now I have confirm that there is a noise when seeking. The noise appears before the seeking, not after.

https://dxr.mozilla.org/mozilla-central/source/dom/media/mediasink/DecodedAudioDataSink.cpp#167

I suspect the | mAudioStream->Cancel();| and |mAudioStream->Shutdown();| make the audio back-end generate a noise, so I add PR_Sleep(100) at the beginning of the function then no noise anymore. But it is only a workaround.
Flags: needinfo?(bechen)

    
    

    
  
Can you comment |mAudioStream->Cancel();| out to see if there is still noice?

    
    

    
  
(In reply to JW Wang [:jwwang] from comment #69)
> Can you comment |mAudioStream->Cancel();| out to see if there is still noice?
It doesn't work.

I had tried some combination of insert delay and comment.

1. no noise
PR_Sleep(100)
mAudioStream->Cancel()
mAudioStream->Shutdown()

2. noise
// mAudioStream->Cancel()
mAudioStream->Shutdown()

3. noise
mAudioStream->Cancel()
PR_Sleep(100)
mAudioStream->Shutdown()

4. no noise
//mAudioStream->Cancel()
PR_Sleep(100)
mAudioStream->Shutdown()

    
    

    
  

      
      
      
      

        Attached audio
          
        SONG_0002.mp3
        — 
      

    


  

    
    

    
  
Is it reproducible without BT?

    
    

    
  
I can see this problem without BT by playing attachment 8702242 [details]. The repro rate is around 55%.

    
    

    
  
Also reproducible on desktop browsers?

    
    

    
  
(In reply to JW Wang [:jwwang] from comment #74)
> Also reproducible on desktop browsers?
Yes. I just tried it on my nightly 46.0a1 and found it is the same as comment 73.

    
    

    
  
(In reply to Blake Wu [:bwu][:blakewu] from comment #75)
> (In reply to JW Wang [:jwwang] from comment #74)
> > Also reproducible on desktop browsers?
> Yes. I just tried it on my nightly 46.0a1 and found it is the same as
> comment 73.

Thanks for Blake's help.
We have test the same file on other browsers/players, only the latest safari and quicktimeplayer on mac don't have the noise when seeking/pausing. Window media player/vlc/firefox/chrome/Audacity have the noise too.
So we guess the noise is a kind of speaker/hardware restrain that only few software fix it.
I will close the bug because I guess the noise we heard is not the same as comment 0 (it should be fixed by sotaro). And file another bug to fix/improve the noise when seeking/pause.

    
  
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE

        Attachment #8681830 -
        Flags: review?(sotaro.ikeda.g)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: