Hey I was browsing thru that code and saw this
bool AudioFlinger::MixerThread::threadLoop()
1190 {
1191 int16_t* curBuf = mMixBuffer;
1192 Vector< sp<Track> > tracksToRemove;
1193 uint32_t mixerStatus = MIXER_IDLE;
1194 nsecs_t standbyTime = systemTime();
1195 size_t mixBufferSize = mFrameCount * mFrameSize;
1196 // FIXME: Relaxed timing because of a certain device that
can't meet latency
1197 // Should be reduced to 2x after the vendor fixes the driver
issue
1198 nsecs_t maxPeriod = seconds(mFrameCount) / mSampleRate * 3;
1199 nsecs_t lastWarning = 0;
1200 bool longStandbyExit = false;
1201 uint32_t activeSleepTime = activeSleepTimeUs();
1202 uint32_t idleSleepTime = idleSleepTimeUs();
1203 uint32_t sleepTime = idleSleepTime;
1204
1205 while (!exitPending())
1206 {
1207 processConfigEvents();
1208
1209 mixerStatus = MIXER_IDLE;
1210 { // scope for mLock
1211
1212 Mutex::Autolock _l(mLock);
1213
1214 if (checkForNewParameters_l()) {
1215 mixBufferSize = mFrameCount * mFrameSize;
1216 // FIXME: Relaxed timing because of a certain
device that can't meet latency
1217 // Should be reduced to 2x after the vendor fixes
the driver issue
1218 maxPeriod = seconds(mFrameCount) / mSampleRate *
3;
1219 activeSleepTime = activeSleepTimeUs();
1220 idleSleepTime = idleSleepTimeUs();
1221 }
1222
1223 const SortedVector< wp<Track> >& activeTracks =
mActiveTracks;
1224
1225 // put audio hardware into standby after short delay
1226 if UNLIKELY((!activeTracks.size() && systemTime() >
standbyTime) ||
1227 mSuspended) {
1228 if (!mStandby) {
1229 LOGV("Audio hardware entering standby, mixer
%p, mSuspended %d\n", this, mSuspended);
1230 mOutput->standby();
1231 mStandby = true;
1232 mBytesWritten = 0;
First they have a comment about a vendor bug with buffer latency -
then they have a macro called UNLIKELY that puts the mixer to
sleep....maybe it's happening in here...?
On May 9, 6:17 am, Hunter Peress <[email protected]> wrote:
> On the nexus one, my app goes into Audio Record Stanby randomly after
> 0-40 seconds. I'm using the AudioRecord class, and while the standby
> is reported in the terminal, the AudioRecord instance reports the same
> states of RECORDSTATE_RECORDING and STATE_INITIALIZED throughout the
> entire sequence.
>
> The bottom line is that when this anomaly occurs, audio is not
> captured. and this is what im working to prevent was only able to
> reproduce on nexus one android2.1 not g1 android1.6
>
> I have looked extensively through the Android C/C++ libraries such as
> at this
> file:http://android.git.kernel.org/?p=platform/hardware/msm7k.git;a=blob_p...
>
> andhttp://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...
>
> Most interesting to me, is this line in
> AudioFlinger:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;...
>
> Specifically the bool AudioFlinger::RecordThread::threadLoop()
>
> As you can see, minput->standby() occurs in 4 different places in the
> code.
>
> I believe that one of these is entering an undesirable state.
>
> Now, I'm looking for a solution. Maybe I've missed something really
> obvious.
>
> Another person's perspective on the issue would be highly appreciated.
> Thank you.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group
> athttp://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
