Use mPrevMixerStatus for DirectOutputThread also.
Remove the MIXER_CONTINUE logic and use MIXER_IDLE instead.
Rename the field mixerStatus to mMixerStatus.
Rename local variable back to mixerStatus.
Change-Id: I0a8145fc856c6c5ff8b784b6176ef3c4d8eb7408
Rename activeTrack to mActiveTrack.
Release the reference earlier, at the end of threadLoop_mix().
This allows the field to be made private and to
move the declaration from PlaybackThread to DirectOutputThread.
Change-Id: I02be7a254638f7d85e92aaf0002d20ca0092a5c3
Move all references to DuplicatingThread::outputTracks and
DuplicatingThread::mOutputTracks from the common threadLoop() into
virtual methods. This allows them to be moved from PlaybackThread to
DuplicatingThread, and to be marked private.
Also use vector assignment to copy mOutputTracks to outputTracks.
Change-Id: Ieb1cf1ad36b8a65143e61e6c92a65fb43427e5e2
The 3rd parameter (param2) to AudioFlingerClient::ioConfigChanged
is used as an input. So changed it from void * to const void *.
It is then cast to const OutputDescriptor *
or const audio_stream_type_t * depending on the event.
Change-Id: Ieec0d284f139b74b3389b5ef69c7935a8e5650ee
Renamed AUDIO_POLICY_OUTPUT_FLAG_INDIRECT to AUDIO_POLICY_OUTPUT_FLAG_NONE
which is more appropriate.
Change-Id: Ia14d60397df0f2dcd9bea0186400a09da35bc104
Continued work on making the copies of threadLoop more similar:
- Remove alias for mActiveTracks in MixerThread and DuplicatingThread.
- Pull in declaration of activeTrack in DirectOutputThread.
- Remove redundant parameter of prepareTracks_l().
- Comment prepareTracks_l().
Change-Id: If1087c1902b454acec01ddfdd9f055f0ca7abf04
Most of these comments will be removed after the threadLoop merge.
Note: the trivial change in assignments to mixBufferSize, and the
comments about "tracks to remove" is to make them all identical.
Change-Id: I3b1a33a7f2cd12ad557a1986bb71f6171161974a
prctl(PR_SET_NAME) limits to 15 characters. Before we had names like
"Binder Thread #" and the counter was cut off :-( Also remove redundant
"thread" at end of name; it's always a thread.
Change-Id: I1f99c2730ba0787ed9b59c15914356cddf698e2f
No need to check for presence of item before removing
(but we do lose the log of the previous value).
Change-Id: I2838430824de5f257f2ee15db0c22b1920c67d08
Change the wording of the logs in the various copies of threadLoop()
to be identical. This will make it easier to merge them soon.
Change-Id: Idfa181e437738712c784dc7f746cac79f83d2931
mixerStatus was being declared (and initialized) too early,
which also resulted in a duplicate initialization. Moved
the declaration into the block where it is actually used.
Change-Id: Ifdcfefe362a5efe3493dd616cdb44645c6f9aed5
Also fix the error handling for the property_get.
This is part of preparation for the threadLoop() merge.
Change-Id: I6405190ea18146d1271575e1dfe9f279e8f36b17
As part of the upcoming threadLoop() merge, this CL makes it clearer
what are the similar and different parts before and after unlocking
effect chains.
In each threadLoop(), the old code was:
if (sleepTime == 0) {
// A
unlockEffectChains(effectChains);
// B
} else {
unlockEffectChains(effectChains);
// C
}
The new code is:
if (sleepTime == 0) {
// A
}
unlockEffectChains(effectChains);
if (sleepTime == 0) {
// B
} else {
// C
}
Also this is slightly slower by one "if", it has the advantage of making
it much more obvious about what is done before and after the unlock,
and also to see the similarities and differences among the various
copies of threadLoop().
Change-Id: I7bf4369d2dcb072573ec43b7e52c637f0097dc00
This is not a real race, because addOutputTrack was only called in two
places, and in both places there could be no other threads referencing
the DuplicatingThread instance.
Those two places are:
- the DuplicatingThread constructor, which is of course safe
- openDuplicateOutput - this is safe because it's called immediately
after the new DuplicatingThread, and there are no sp<> either in the
constructor or here which could cause onFirstRef() to do Thread::run().
But for safety in case addOutputTrack is ever called somewhere else,
or there are sp<> created earlier, it is safer to take the thread lock.
Change-Id: I1502d014fa37ec5dbf4bf40d3e2884af311cd5e9
Add comments about which methods implement the AudioBufferProvider interface.
Simplified the definition of kInvalidPts. <stdint.h> is very hard to work
with, there seems to be no way to use it reliably to get INT64_MAX without
having a separate source file, which is ugly because it means kInvalidPts
is not a compile-time constant. So I just deleted AudioBufferProvider.cpp
and used a hard-coded constant instead.
Added a default constructor for Buffer so that the fields aren't random
(especially .raw which is used to determine if the buffer is valid).
Make the pts for getNextBuffer default to kInvalidPTS so code that
doesn't need a pts doesn't have to specify a value.
Rename the parameter to AudioMixer::setBufferProvider to make it clearer.
Change-Id: I87e7290884d4ed975b019f62d1ab6ae2bc5065a5
At end of AudioFlinger::onFirstRef(), the hardware status was being left
in wrong state. It should be AUDIO_HW_IDLE but was AUDIO_HW_INIT.
mHardwareStatus was being set to AUDIO_HW_OUTPUT_OPEN too early, and so
a return would leave it in the wrong state until next hardware operation.
Take the hardware lock for dev->get_parameters, and update mHardwareStatus
before and after.
Keep hardware lock only for the duration of the dev->set_parameters.
Rename two constants in enum hardware_call_state to have the prefix
AUDIO_HW so they follow the naming conventions.
Add comments.
Change-Id: I6c7450b11f9b13adaeef9cec874333e478a58fc0
The bit-field TrackBase::mFlags was supposed to have track-specific
flags in the upper 16 bits, and system flags in the lower 16 bits.
The upper 16 bits of mFlags were initialized in the TrackBase
constructor from the flags parameter of IAudioFlinger::createTrack()
and IAudioFlinger::openRecord(), and the lower 16 bits were cleared.
However, the upper 16 bits of mFlags were never acccessed again.
So really there are no track-specific flags. I left the flags
in the parameter list of createTrack() and openRecord() but made a
note that these should be removed eventually as they are dead.
This leaves only the one system flag "step server failed". I replaced
the bit-field mFlags by bool mStepServerFailed, which is simpler and
slightly faster.
Change-Id: I6650f5487be72791b4a67d73adcd10ffa04e2aa5
Avoid using wp<>::unsafe_get() except in a log, and other specific cases
when it's known to be safe.
Use more specific subclass types for parameters to avoid down-casts.
When a constructor or method parameter is "this" of an object that is
currently being constructed, it's better to use a raw pointer rather
than either sp<> or wp<>.
Using the raw pointer is safe, provided either:
- it is "this" of an object being constructed (which has sp<> refcount of 0),
- or the caller already holds an sp<>
The raw pointer is simpler and faster, and it avoids the problem of the
sp<> reference count being incremented and then decremented to zero on
scope exit, which would cause the object's destructor to run while the
object is still being constructed.
Also removed some dead code per a review comment.
Change-Id: I7375f64da3aec11b928c33cb01faff186252ef5e
