937060 - [Flatfish] [Music] Music App can not resume playing file after pause

Status: RESOLVED INACTIVE

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

Description

[RaymondSu]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36

Steps to reproduce:

1. Launch Music App
2. Choose a song to play
3. Pause and then press resume icon
4. Check the music sound



Actual results:

Resume can not work (I tested with .MP3 song)


Expected results:

Play/Pause/Resume function normally

Comment 1

[Francis Lee [:frlee]]

hi Dominic, 

are you able to check this bug?

Comment 2

[amitav.anand]

This issue is reproducible on Nexus-4 with above steps. Just noticed, if we seek the audio from where we paused, it plays fine and after that subsequent Pause and resume works. 
Timed out waiting for output buffers: is signaled from waitForBufferFilled_l in OMXCodec.cpp. After Pause, the mFilledBuffers.empty() is true, so we get an error in waitForBufferFilled_l(). Below is the code:-
while (mState != ERROR && !mNoMoreOutputData && mFilledBuffers.empty()) 
   {
        if ((err = waitForBufferFilled_l()) != OK) 
        {
            return err;
        }
    }
Investigating more on the issue.

Comment 3

[amitav.anand]

Attachment: Video-Pause/Resume Issue

Comment 4

[Sotaro Ikeda [:sotaro]]

This seems a dup of Bug 919590.

Comment 5

[amitav.anand]

attached a video for the issue. Play a MP3 file from Music App -> Pause -> Resume. The audio plays for 1 sec after resume(Audio plays for the amount of data that was present in input buffer during pause and then stops). 
It seems the OMX component does not get any new buffer.
Getting issue:- called start in the unexpected state : 4
status_t OMXCodec::start(MetaData *meta) {
    Mutex::Autolock autoLock(mLock);
    CODEC_LOGV("Enter OMXCodec::start with mState:%d",mState);
    if (mState != LOADED) {
        CODEC_LOGE("called start in the unexpected state: %d", mState);
        return UNKNOWN_ERROR;
    }

Comment 6

[Dominic Kuo [:dkuo]]

(In reply to Francis Lee [:frlee] from comment #1)
> hi Dominic, 
> 
> are you able to check this bug?

I think this should be a gecko issue so we might need some help from the gecko side, Bruce, can you help to investigate this and see if it belongs to "Core::Video/Audio" component? or a duplicate of bug 919590? thanks.

Comment 7

[amitav.anand]

Attachment: 937060_Fix.patch

Comment 8

[amitav.anand]

Proposed Fix. This works on Nexus-4. Made some tweaks in the Sotaro's Patch(attachment 817942 [details] [diff] [review] and attachment 817944 [details] [diff] [review]) from bug 919590.

Comment 9

[Bruce Sun [:brsun]]

This bug is similar to bug 919590. The usages of OMXCodec::start() and OMXCodec::pause() are needed to be refined while OmxDecoder::Play() and OmxDecoder::Pause() are invoked.

Comment 10

[Eric Chang [:ericcc] [:echang]]

"16Khz 32Khz 2Channels MPEG2 layer3" -> has this problem...
"44.1KHz 40Kbps 2channels MPEG1 layer3" -> not with this format.

Comment 11

[Bruce Sun [:brsun]]

(In reply to Eric Chang [:ericcc] [:echang] from comment #10)
> "16Khz 32Khz 2Channels MPEG2 layer3" -> has this problem...
> "44.1KHz 40Kbps 2channels MPEG1 layer3" -> not with this format.

Would you please help upload these testing clips for our reference?

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to amitav.anand from comment #7)
> Created attachment 8334471 [details] [diff] [review]
> 937060_Fix.patch

attachment 8340486 [details] [diff] [review] seems simpler and better now.

Comment 13

[Francis Lee [:frlee]]

hi Bruce,

may i know the status of the fix patch in comment #7? if it can fix this issue, when do you plan to land it?

Comment 14

[Bruce Sun [:brsun]]

Hi Francis,

This bug is similar to bug 919590. Although the underlying OMX IL components are different on these two bugs (one is referring to H.264 video decoder, and another one is referring to MP3 audio decoder), the solutions to these two problems would be the same. If bug 919590 can be solved, than this bug will also be resolved as well.

There are two different solutions on bug 919590 already and waiting for further feedback:
1. Solved in gecko: attachment 817944 [details] [diff] [review] and attachment 8334361 [details] [diff] [review]
2. Solved in gonk: attachment 8340486 [details] [diff] [review]

Comment 15

[Bruce Sun [:brsun]]

Hi Sotaro,

Would you please share your comments for Francis's question? Thanks in advance.

Comment 16

[Sotaro Ikeda [:sotaro]]

> Would you please share your comments for Francis's question? Thanks in
> advance.

My thought was changed since Bug 919590 creation. I feel it seems better to be fixed by changing OmxDecoder::Pause(). See Bug 919590 Comment 36, Bug 919590 Comment 37. OmxDecoder::Pause() is out side of the gekoc. It is gonk area. Flatfish seems to have a own repository for gonk. It seems better to fix the problem by changing gonk side. Other hw vendor already seems to fixe the problem by it. See Bug 919590 Comment 34.

Comment 17

[Francis Lee [:frlee]]

hi Sotaro,

based Bug 919590 Comment 40, when you land your 919590's patch (in review status), i suppose that this current issue will be fixed as well? could you please kindly confirm it?

Comment 18

[Sotaro Ikeda [:sotaro]]

> i suppose that this current issue will be fixed as well?

Sorry, I never use flatfish, I do not know about it.

If the attachment 8340486 [details] [diff] [review] could get "review+", I am going to land to the following.
https://github.com/mozilla-b2g/platform_frameworks_av/tree/b2g-4.3_r2.1

The flatfish seems to have a different repository for "frameworks/av". So, the problem could be handled independently.

Comment 19

[Jeff Chuang]

(In reply to Sotaro Ikeda [:sotaro] from comment #18)
> > i suppose that this current issue will be fixed as well?
> 
> The flatfish seems to have a different repository for "frameworks/av". So,
> the problem could be handled independently.

I have tried the patch 937060_Fix.patch on flatfish and it works fine for both music player and video player.
My code base is as flowing:
---Gecko---
commit c63c0a68f58a026e2b1fb8eca89ccd1e5c11adf6
Author: Mike Hommey <[e-mail]>
Date:   Mon Dec 9 13:39:26 2013 +0900
---Gaia---
commit 1abda08e450cb66a61a31bdcfd3352e2df9d9ace
Author: Michael Henretty <[e-mail]>
Date:   Fri Dec 6 22:01:04 2013 -0800

Comment 20

[RaymondSu]

Attachment: tapping the Timeline

Update the test result:
Tap the MP3 file --> Music player will play the MP3 file automatically.
If this MP3 can NOT resume playing after pause, just touching or dragging the timeline can "recover" this failure! (ref. the attachment.)

Seems like this bug happened while those conditions:
1. "16Khz 32Khz 2Channels MPEG2 layer3"
2. start playing automatically while tapping the MP3 file
3. Without touch the timeline

Comment 21

[Jason Smith [:jsmith]]

I'm unsure why this would be 1.3 blocker specifically, as I don't recall work happening for flatfish on any branch other than trunk. Renominating for more discussion.

Comment 22

[Jason Smith [:jsmith]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=944594#c5.

Comment 23

[Francis Lee [:frlee]]

contribution program build will be based on master-C. remove 1.3? flag.

Comment 24

[eva.chen.fx]

Update the audio test result:
Repro frequency: 100%
1) MP3 and M4A audio format, resume can't work.
2) WAV audio format, resume function normally.

This bug can be reproduce at,
DUT: Flatfish tablet
Gaia: 9943f1984b9a50d721a05a60a9476215841ca536
Gecko: 34929c20963c6d6e5eac43fbeb7cde0a28b0cb02
B2G: 2.1.0.0-prerelease
firmware revision: flatfish_20140630-0040
Platform version : 33.0a1
Builder Identifier: 20140630005021

Comment 26

[Joe Young]

see bug 957467 comment #23

Comment 27

[Nils Ohlmeier [:drno]]

Mass closing because of inactivity.
Please feel free to re-open if still relevant.