I suppose you are seeing this on a Nexus 5? If not which device?
Which version of KK are you running?
I think the right fix is to systematically resume HW if a track is active.
This implies moving the if (mHwPaused) {} block from block if
(track->mState == TrackBase::RESUMING) { } to after mixerStatus =
MIXER_TRACKS_READY; in if (last) {} block.
We also need to handle the case where we are in STOPPING_1 and no data is
left in the track buffer but we still have data not sent to the HAL in the
mix buffer.
This requires modifying the if (track->isStopping_1()) {} block to always
do if (mHwPaused) {...} if processing last track and not only
if mBytesRemaining == 0.
Could you upload a CL on AOSP and we will follow up from there?
Thanks for pointing this out.
On Tuesday, March 4, 2014 11:10:32 PM UTC-8, Bala Murugan wrote:
>
> Hi,
>
> I recently came across a situation as below, which leads to
> playback/Video freeze.
>
> The exact scenario is,
>
> 1. Video is playrd with gallery app, and the user does *seek* to
> somewhere near 20 seconds to end.
> 2. User keeps pressing pause and resume.
> 3. At some point in time, while user keeps pausing and resuming, when
> Audioplayer EOS received from Audio source, it calls
> *PlaybackThread::Track::stop
> *which will make the state to *STOPPING_1 *as there is a data still in
> mCblk and under run is not occurred yet.
>
> 4. And thereafter while playing at *STOPPING_1*,
> * AudioFlinger::PlaybackThread::threadLoop_Write* calls *out_write* and
> gets 0 as return value since driver buffer is full.
> So, Playback thread waits for *mWriteAckSequence* to become even
> number i.e, basically waits for acknowledgement from driver, using
> *poll*systemcall in tinycompress.
>
> 5. At this point user presses "*Pause*" button.
>
> 6. Now, Offload command thread(in HAL) is kept waiting at poll. And, as
> compress_pause has been triggered the driver to stop rendering.
> So, driver buffer will not be freed until compress_resume is called.
>
> 7. Now, when user presses "*Resume*" button, and at this stage, there
> is still data in *mCBlk*, So, track moves to *STOPPING_1* state. In
> prepareTracks_l, there is no code to call the *out_resume* to resume the
> playback.
>
> 8. So, I added the below patch, which makes the playback to continue
> further properly.
> I just want to check, Is this a problem, as poll is not returned or
> if not, is my patch a valid one, and can be commited?
>
> diff --git a/services/audioflinger/Threads.cpp
> b/services/audioflinger/Threads.cpp
> index 498ddb6..14ab3d0 100644
> --- a/services/audioflinger/Threads.cpp
> +++ b/services/audioflinger/Threads.cpp
> @@ -4058,7 +4058,11 @@ AudioFlinger::PlaybackThread::mixer_state
> AudioFlinger::OffloadThread::prepareTr
> track->mRetryCount = kMaxTrackRetriesOffload;
> mActiveTrack = t;
> mixerStatus = MIXER_TRACKS_READY;
> - }
> + } else if (track->isStopping_1() && track->framesReady() &&
> (mWriteAckSequence & 1) && mHwPaused) {
> + doHwResume = true;
> + mHwPaused = false;
> + }
> +
> } else {
> ALOGVV("OffloadThread: track %d s=%08x [NOT READY]",
> track->name(), cblk->mServer);
> if (track->isStopping_1()) {
>
>
> Thanks,
> Bala
>
--
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
