Hi Glenn,
this issue nearlly 100% happenes on my device.
i have checked 4.2 code, it seemed that has fixed this issue, but i am not
sure the exact solution.
below is the dump info:
FastMixer command=COLD_IDLE writeSequence=1052 framesWritten=403968
numTracks=1 writeErrors=0 underruns=66 overruns=115
sampleRate=48000 frameCount=768 measuredWarmup=17.4 ms,
warmupCycles=2
mixPeriod=16.00 ms
Simple moving statistics over last 8.4 seconds:
wall clock time in ms per mix cycle:
mean=15.76 min=0.34 max=55.36 stddev=11.69
raw CPU load in us per mix cycle:
mean=326 min=0 max=824 stddev=121
Fast tracks: kMaxFastTracks=8 activeMask=0x1
Index Active Full Partial Empty Recent Ready
0 yes 519 3 2 full 1920
1 no 0 0 0 full 0
2 no 0 0 0 full 0
3 no 0 0 0 full 0
4 no 0 0 0 full 0
5 no 0 0 0 full 0
6 no 0 0 0 full 0
7 no 0 0 0 full 0
State queue observer: stateChanges=5
State queue mutator: pushDirty=5 pushAck=2 blockedSequence=4
Output thread 0x42620008 stream volumes in dB:
0:0, 1:-17, 2:-17, 3:-11, 4:-4.6, 5:-17, 6:-6.6, 7:-29, 8:-30, 9:-14,
10:-14
Output thread 0x42620008 tracks
Name Client Type Fmt Chn mask Session mFrCnt fCount S M F SRate L dB
R dB Server User Main buf Aux Buf Flags Underruns
Output thread 0x42620008 active tracks
Name Client Type Fmt Chn mask Session mFrCnt fCount S M F SRate L dB
R dB Server User Main buf Aux Buf Flags Underruns
Normal mixer raw underrun counters: partial=3 empty=2
- 0 Effect Chains:
AudioHardwareBase::dumpState
mMode: 0
在 2012年12月18日星期二UTC+8下午11时05分39秒，Glenn Kasten写道：
>
> I have not seen this happen on my test devices so far.
> Which device are you having the problem on?
> Does the same problem happen on all other devices you try, or only this
> one?
> Is it 100% repeatable, or only happens sometimes?
> Please supply output of adb shell dumpsys media.audio_flinger
> and the last 20 lines of adb logcat immediately after a failure.
>
> On Wednesday, December 12, 2012 9:59:14 PM UTC-8, eleven wrote:
>>
>> Dear Glenn,
>>
>> I met a issue when I hang up a phone call after communication.
>> When hang up a phone call, there will be a notification stream from
>> earpiece to
>> notify user that phone call is ended.
>>
>> From the log, ToneGenerator will create a FastTrack to play it.
>>
>> And the Question is after palying the sound, this FastTrack will be set
>> to
>> TERMINATED state and stay in Active state in MixerThread.
>>
>> After track the code, I found that below function never return ture:
>>
>> if (!track->presentationComplete(framesWritten, audioHALFrames)) {
>> // track stays in active list until presentation is complete
>> break;
>> }
>>
>>
>> bool AudioFlinger::PlaybackThread::Track::presentationComplete(size_t
>> framesWritten, size_t audioHalFrames)
>> {
>> // a track is considered presented when the total number of frames
>> written
>> to audio HAL
>> // corresponds to the number of frames written when
>> presentationComplete()
>> is called for the
>> // first time (mPresentationCompleteFrames == 0) plus the buffer
>> filling
>> status at that time.
>> if (mPresentationCompleteFrames == 0) {
>> mPresentationCompleteFrames = framesWritten + audioHalFrames;
>> ALOGV("presentationComplete() reset: mPresentationCompleteFrames
>> %d
>> audioHalFrames %d",
>> mPresentationCompleteFrames, audioHalFrames);
>> }
>> if (framesWritten >= mPresentationCompleteFrames) {
>> ALOGV("presentationComplete() session %d complete: framesWritten
>> %d",
>> mSessionId, framesWritten);
>> triggerEvents(AudioSystem::SYNC_EVENT_PRESENTATION_COMPLETE);
>> return true;
>> }
>> return false;
>> }
>>
>> After add some log to track I found that "framesWritten" alwasy be 0,
>> because in
>> playtrackthread, mBytesWritten was reset to 0 at the front of
>> PlaybackThread::threadLoop()
>> // put audio hardware into standby after short delay
>> if (CC_UNLIKELY((!mActiveTracks.size() && systemTime() >
>> standbyTime) ||
>> mSuspended > 0)) {
>> if (!mStandby) {
>>
>> threadLoop_standby();
>>
>> mStandby = true;
>> mBytesWritten = 0;
>> }
>>
>> Because it will just call presentationComplete() after Track's state
>> becomming
>> STOPPING_2 or TERMINATED.So the question is why Track's state changed so
>> slow
>> which make the next suspend operation reset the mBytesWritten always ??
>>
>> BTW, I tried to make the mixerThread suspend just after
>> mActiveTracks.size
>> =0,which means waiting FastTrack finish its presentationComplete.
>> but it still failed, because when Clinet AP call track's stop function,
>> it will
>> also stop writing, and mBytesWritten also can not get increased, so
>> presentationComplete will never return true.
>>
>> it is very weird !! And our platform support FastMixer, after happened
>> this, the
>> mixerthread will keep pushing state into FastMixer.
>>
>> Could you help me ?
>>
>> Thanks
>>
>>
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
