If the pause request is received before the AudioTrack buffer was
completelly filled and the track ready for mixing, the pause is
not executed: the track just underruns and stays in pausing state.
The fix consists in considering the track ready for mixing immediately
if pausing.
Change-Id: Ia6cb4703fee2126e41011a6400ea8eeb3a3e5456
This issue showed that when an AudioTrack underruns during a too long period
of time and is therefore disabled by audioflinger mixer, it takes an additional
delay of up to 3 seconds to recover.
This fix adds a simple mechanism to recover immediately when the client application
is ready to write data again in the AudioTrack buffer
Also throttle warnings on record overflows
Change-Id: I8b2c71578dd134b9e60a15ee4d91b70f3799cb3d
Fixed the following issues in LVM effect bundle wrapper:
- memory leaks in EffectCreate() in case effect creation fails at various stages
- Added saturation when accumulating to output buffer
- Fixed problems with enabled effects count when an effect is released while enabled
- Do not allocate temporary buffer for accumulation each time process() is called
Fixed the following issues in effects framework (AudioFlinger)
- Release effect synchronously in the library when deleted from effect chain
- Do not call the effect process function if no tracks are present in the same
audio session
Change-Id: Ifbd80a163415cfb3c0a337c12082853ea45d9c91
Removed a cross deadlock condition between audioflinger and audio policy
service mutexes.
Audioflinger::createEffect() locks audioflinger mutex and then calls
AudioSystem::getOutputForEffect() which ends up in
AudioPolicyService::getOutputForEffect() which locks audio policy service
mutex. If at the same time, the command thread in audio policy service is
processing a command(set volume, set route...), the mutex is locked and the
command will call one audioflinger method which in turn will attempt to
lock audioflinger mutex.
The fix consists in releasing audioflinger mutex before calling
getOutputForEffect().
Change-Id: Id44e7feb36e0a295731f6aa97cf32d022edd34d0
Applications creating an audio effect on the output mix must
have the MODIFY_AUDIO_SETTINGS permission.
Change-Id: I57d88533f91ad0d33680107d79abcec28f7263b5
- Use a constant input level to the reverb engine and implement volume control in the
insert reverb. This avoids the volume spikes when an effect that was inserted after
the reverb is disabled or removed.
- Fix clicks (one silent buffer) at the end of the reverb disable period.
- Modified volume management in audioflinger so that the volume ramp is also done by
the insert effect if present when the track is paused (avoids clicks).
- Increased room level for all presets.
Also fixed problems with output stage session (-1):
- effect bundle wrapper was not designed to support session -1
- the permission check in audioflinger for using session -1 failed due to a wrong usage of
getCallingPid()
Change-Id: Id1ff51327263364bf71d3f2668fa5cde4311d84f
The *pReplyData argument of the command() function was left unitialized by EffectHandle::command()
when command was EFFECT_CMD_ENABLE, EFFECT_CMD_DISABLE and EFFECT_CMD_SET_PARAM_COMMIT.
Change-Id: I91a19817ead2a8cfbdd8e2d77ca270c7ce9d5bd4
- Fixed click when re-enabling effect during the turn off phase:
make sure the effect states where effect is processed are the same
where volume control is delegated to effect.
- Fixed click when effect is deleted while still active: do not apply
volume ramp if an effect having volume control was just removed from the
effect chain.
Also fixed a crash when PCM dump is enabled in effect bundle wrapper.
Change-Id: Ib562f5cf75c69af75df0e862536262e2514493e4
The problem is that the audio policy manager does not handle the input devices
when forced use for telephony is changed.
The problem does not appear in a call over PSTN becasue only teh output devices drives the
routing of in call audio to/from the base band.
The fix consists in modifying AudioPolicyManagerBase::setForceUse() to check for active inputs
and update the input device if needed.
Change-Id: I0d36d1f5eef1cce527929180c29b025439902f10
Fixed regression introduced by change a54d7d3d7dd691334189aab20d23c65710092869 in audioflinger mixer thread:
When the output stream is suspended, the sleep time between two writes must match the actual duration
of one output stream buffer otherwise the playback rate is not respected.
Change-Id: Ic5bebe890290d1f44aeff9dd3c142d18e26fff2a
Fixed regression introduced by commit 2a6b80bc65c4782b5a7168b300e1dc5ec9f617ee:
master mute was not working if no effect chains were present on session 0.
Change-Id: I66d107e045d159cb94d29c7476fa1e12d92f2ae7
- Fixed constant inversions in AudioEffect.java
- Do not return error when enabling an already enabled effect
- Update cached effect state in native AudioEffect class when effect is enabled/disabled by command() method
- Remove click when restarting effect during disable sequence
- Fixed problem in master mute management when volume control is delegated to effect.
Change-Id: I6df4ce9fcc54fdc7345df858f639d20d802d6712
When all audio tracks have been disabled and the mixer is running idle before the output stream is placed in standby,
the mixer sometimes fails to write to the output stream on time to avoid underrun.
This is because the sleep period used to wait before the next write to output stream is too close to the actual buffer duration.
In fact this sleep time is not critical as if we write too early to the output stream, the kernel driver will wait for free buffers
from the audio DSP DMA and we will sleep anyways.
The fix consists in dividing the calculated wait period by 2 to increase the margin.
Change-Id: I5730887dc2ccce2a511bc858494a6f7da6b392a0
Merge commit '45dc4f82a00e52b12389b22a7cfbbee5609e8e28'
* commit '45dc4f82a00e52b12389b22a7cfbbee5609e8e28':
Allow creation of an audio effect on a session with no audio tracks.
This is necessary to allow creating and enabling an effect attached to a particular player
session before the playback is started. As a matter of fact, the implementation of the mediaplayer
does not create the AudioTrack before playback starts.
Change-Id: I1266e8885f9d756acc949303321aaac0fbf83e34
The type of the cmd, cmdSize and *pReplySize parameters of the effect control interface command()
function have been modified from int to uint32_t. This is more consistent with their role.
Change-Id: I84d289fc262d6753747910f06f485597dfee6591
Added methods for audio effects management by audio policy manager.
- control of total CPU load and memory used by effect engines
- selection of output stream for global effects
- added audio session id in parameter list for startOutput() and stopOutput().
this is not used in default audio policy manager implementation.
Modifications of audio effect framework in AudioFlinger to allow moving and reconfiguring
effect engines from one output mixer thread to another when audio tracks in the same session
are moved or when requested by audio policy manager.
Also fixed mutex deadlock problem with effect chains locks.
Change-Id: Ida43484b06e9b890d6b9e53c13958d042720ebdb
Fixed the following problems in audio effect volume control in AudioFlinger:
- Make sure that the volumes returned by EffectChain::setVolume_l() are correct even is
no change is detected since last call
- Do not use isEnabled() to validate volume control but mState >= ACTIVE instead as the volume control
must be also active in STOPPING and STOPPED states.
Change-Id: Id62da3164fad500ee8a5efd6cd78c77e8fdcb541
- Fixed crash when deleting an effect chained before an effect having volume control
- Changed EFFECT_FLAG_VOLUME_CTRL to implicitely include EFFECT_FLAG_VOLUME_IND
(not need to set both in effect descriptor).
- Volume control changes from one effect to another if needed according to effect enable state
- EFFECT_CMD_SET_VOLUME is only sent when their is an actual change in volume
Change-Id: Ieebaf09157e2627366023569d95516646e03e26c
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Iee42b83dd2a94c3bf5107ab0895fe2dfcd5337a8
