Add a non-default constructor to set the mSessionId, and make mSessionId const.
Remove explicit clear on mEffects - it is automatically cleared by the destructor.
AudioPolicyService::setPreProcessorEnabled:
- parameter is const *
- use an alias instead of making a Vector copy
Destructor doesn't need to be virtual since there are no subclasses.
Change-Id: Ibc3c3bea8259839430b1cf5356186c7d96f1082f
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
