Only increase the counter when we do take a wakelock

We keep track on how many wakelocks we have taken. We always
just take one real wakelock but increase / decrease the
counter every time we try to acquire / release a wakelock.
The counter is always increased even if the power manager is
not ready, leading to an incorrect counter that could cause a
crash when we try to release it.
Make sure we only increase the counter when a wakelock, real
or counted, is taken.

Change-Id: Iad940e052694932f1dad8a1a71fa63601d289d6a
update offloaded audio track sampling rate

AudioPlayer must read the sampling rate from offloaded audio sinks
whenever a new time position is computed as the decoder can update
the sampling rate on the fly.

Change-Id: I997e5248cfd4017aeceb4e11689324ded2a5bc88
AudioTrack: fix position callback after restore

When restoring an AudioTrack, the next position callback point
should not be modified and set ahead of current buffer head.
Otherwise, as frames are dropped, the new position is never reached
and an application relying on position callbacks to reload the buffer
would be stalled.

Bug: 11868603.
Change-Id: I93b2a311642a0c89944b78bcc0482d4ceed98ae4
fix deadlock issues that arise when there are simultaneous
effect control interface calls to proxy and to
non sub-effect wrappers(eg., bundlewrapper) from audioflinger
Also, return NO_ERROR when CMD_OFFLOAD succeeds

Whenever there are parallel calls to proxy and non sub-effects wrappers,
some of the calls are not completed. This is due to deadlock arsing out
of Proxy waiting for the subeffect call to return and subeffect waiting
for proxy to release lock.
The call flow is changed to a cleaner and simple one - Proxy gets the
aeli(effect library info) of subeffects during the EffectGetSubEffects()
call. Therby, proxy will manage the sub effects by itself rather than
going through effects factory.

Signed-off-by: jpadmana <jayashree.r.padmanaban@intel.com>
Bug: 12424044
Change-Id: I16852222f1d0e94e433a19177729323a4bb1c090
audioflinger: fix static track end detection

If a static track is not a fast track,
prepareTracks_l() must rely on framesReady() to
detect end of buffer and remove the track from the active
track list.
Failing to do so results in the track staying active but
not processed by the mixer because in underrun. This leaves the
mix buffer content uninitialized and causes the effect process
function to accumulate its output onto undefined data.

Bug: 12013676.
Change-Id: Iad72c921fa18d34811abf7d1073890c093a27725
AudioTrack: Never try to use the fast path if resampling is required

Unless AudioFlinger was built with FAST_TRACKS_AT_NON_NATIVE_SAMPLE_RATE
enabled, AudioFlinger would deny using the fast path (and internally
fall back to the normal codepath) when it realized that resampling
was required. Since the buffer size calculations within AudioFlinger
don't take resampling into account properly (see the calculation
below "AUDIO_OUTPUT_FLAG_FAST denied" in audioflinger/Threads.cpp,
just below the hunk that this patch changes), make sure AudioTrack
doesn't try to use the fast path if resampling is required.

This removes the possibility to enable
FAST_TRACKS_AT_NON_NATIVE_SAMPLE_RATE in AudioFlinger since it
AudioTrack now won't even try to use the fast path for content
that requires resampling, regardless of the AudioFlinger configuration.

Change-Id: Icf0f8ad50bf0fdb84657f518c0120aa0535f23f9
AudioFlinger: Remove code for supporting resampling in fast tracks

This isn't used at the moment.

Change-Id: I4e0fb2af5f7d959dbafd5ddb7defa1c6b8e8636a
Merge pull request #21 from CyanogenMod/cm-11.0

update fork