When an AudioTrack is in underrun state, the AudioFlinger mixer will
sleep for a short period of time to give the app a chance to fill the
AudioTrack buffer. If the AudioTrack is still not ready during next mixing round,
the mixer will proceed with other tracks.
If an application keeps a steady underrun condition, the AudioFlinger mixer will
alternate between ready and not ready states. In the longer term this will cause the
audio HAL to underrun.
There is a mechanism to reduce the sleep period if the mixer is not ready several times in a
row but this mechanism is defeated by the alternating ready/not ready conditions.
The fix consists in only increasing sleep time if the mixer is ready for at least two
consecutive times.
Issue 5904527.
Change-Id: Id0139bca9be8c4e425ec6d428515c4d8f718e8c9
This problem due to the way audio buffers are mixed when
low power mode is active was addressed by commits 19ddf0eb
and 8a04fe03 but only partially. As a matter of fact, when more
than one audio track is playing, the problem is still present.
This is most noticeable when playing music with screen off
and a notification or navigation instruction is played: in this case,
the music or notification is likely to skip.
The fix consists in declaring the mixer ready if all active tracks
are ready. Previous behavior was to declare ready if at least one track was
ready. To avoid that one application failing to fill the track buffer blocks other
tracks indefinitely, this condition is respected only if the mixer was ready
in the previous round.
Issue 5799167.
Change-Id: Iabd4ca08d3d45f563d9824c8a03c2c68a43ae179
The calculation done in prepareTracks_l() for the minimum amount
off frames needed to mix one output buffer had 2 issues:
- the additional sample needed for interpolation was not included
- the fact that the resampler does not acknowledge the frames consumed
immediately after each mixing round but only once all frames requested have been used
was not taken into account.
Thus the number of frames available in track buffer could be considered sufficient although
it was not and the resampler would abort producing a short silence perceived as a click.
Issue 5727099.
Change-Id: I7419847a7474c7d9f9170bedd0a636132262142c
The maximum sleep time allowed in the mixer thread when audio tracks
are enabled but not ready for mixing is derived from the latency
reported by the output stream.
This does not work for A2DP where the latency also reflects encoding, decoding
and transfer time.
Modified activeSleepTimeUs() to take A2DP case into account.
Issue 5682206.
Change-Id: I3784ac01fb6f836b5a6ce6f764fb15347586de35
Progressively reduce the sleep time applied in MixerThread::threadLoop()
in case of consecutive application underruns to avoid starving the audio HAL.
As the default sleep time is longer than the duration of an audio buffer
we ended up writing less data than needed by the audio HAL if
the condition persisted.
Issue 5553055.
Change-Id: I2b23ee79c032efa945025db228beaecd1e07a2e5
When audio effects are enabled, a noise can be heard at the
beginning of the new song when skipping to next song in music app.
This is because some effects (especially virtualizer) have a tail.
This tail was not played when previous song was stopped because effects were
not processed when no tracks were present on a given session. This is to
reduce CPU load when effects are enabled but no audio is playing.
The tail was then rendered when the new song was started.
Added a delay before stopping effect process after all tracks have been removed from a session.
Issue 5584880.
Change-Id: I815e0f7441f9302e8dfe413dc269a94e4cc6fd95
Commit 19ddf0eb introduced a problem with applications (like SoundPool)
relying on an underrun condition to detect end of playback instead of
stopping the track when all data is written.
AudioFlinger would keep waiting for new data in case of partial buffer
filling and never reach the underrun condition.
Added a mechanism to wait no more than once if not enough frames are present
in the track buffer.
Issue 5585490.
Change-Id: I131e605ff6070831a01ddf734e68459e3bf2354b
The addition of low power audio playback mode made that audio buffer consumption
by audio HAL can now happen in bursts. This makes that requesting audio data
from an AudioTrack for mixing can happen at much shorter intervals than before.
This revealed an existing problem where AudioFlinger would consider a track ready
for mixing although not enough frames were ready to completely fill one output buffer,
thus creating short periods of silence.
The fix consists in waiting for enough frames to be ready in AudioTrack buffer before
declaring a track ready for mixing. This minimum is not applied when the track is stopped
to allow the buffer to be emptied completely.
Change-Id: I6d04f9b65db5af85b0b53f0a5674be7ec02f9e9f
When AudioEffectTest is executed, an Equalizer is created
and enabled on a MediaPlayer session. Effects on the output
mix are therefore suspended.
Then the MediaPlayer is released with the effect still enabled.
In this case, Audioflinger::purgeStaleEffects_l() fails to restore
the suspended effects when the effect attached to the released audio session
is removed.
When subsequent tests are executed on output mix effects, these effects cannot be
enabled as they are still suspended.
Fixed purgeStaleEffects_l() to restore suspended effects if the effect removed is enabled.
Also fixed EffectHandle::disconnect() to only restore suspended effects if the disconnected
handle actually has control over the effect.
Change-Id: I67232e7c34680b0cc01abfd57d5d510a524e5d4f
AudioFlinger logs a warning when a write to the audio HAL
takes too long to return. The threshold for this warning is
a rule of thumb based on the assumption that the audio HAL will consume
buffers at a regular pace.
The introduction of low power audio mode with larger buffers and writes
occuring in bursts makes that this threshold is often exceeded resulting
in excessive and misleading warnings.
The threshold is raised to remove unwanted warnings but we should reconsider
the usefulness of this warning altogether.
Change-Id: I5ef6898ea28d879cede3e47da542a64092a3cca4
This problem only occurs when audio effects are present and
the music volume is applied by one effect engine.
When connecting or disconnecting A2DP, audio effects are moved from
one mixer thread to another. When removed from the source thread,
the effect is stopped but it is not restarted when added to the
destination thread.
This regression was introduced by commit 21b5c47e.
Change-Id: I4cc578d8d760ec65b185032b6fda98c739d331bc
Fixed several regressions in automated audio effect tests due
to changes in effect framework and visualizer FFT output range.
- Do not suspend Volume effect on session 0 when effects are
enabled on specific sessions.
- Adapt energy detection thresholds to new visualizer FFT range.
- Leave more time for BassBoost and Virtualizer effects to ramp up
before measuring the effect.
- Removed second insert reverb left by mistake on the player session
in preset reverb test.
Change-Id: I7a1ad1372d783fa7900eb9dd1d3b47f54d8d766f
There is a possiblility that the condition on which RecordThread::checkForNewParameters_l()
waits after updating the command completion status is never signalled.
This happens if the thread executing ThreadBase::setParameters() has timed out waiting
for the status (for instance if the audio HAL takes too long to execute the setParameters()
command. Then the RecordThread is stuck forever.
The fix consists in waiting for the condition with a timeout in RecordThread::checkForNewParameters_l().
Change-Id: I7fc671bc2fc43ba4acb65a2beb33ee05742f091e
When the A2DP headset is connected, there is a possible
race condition when the audio tracks are moved from
the mixer thread attached to the speaker output to the thread
attached to A2DP output.
As the request to clear the stream type to output mapping cache in
the client process is asynchronous, it is possible that the flag
indicating to the client audio track to re-create the IAudioTrack
on the new thread is processed before the cache is invalidated.
In this case, the track will be attached to the old thread and
music will continue playing over the device speaker instead of being
redirected to A2DP headset.
Change-Id: Ib2ce1eb5320eaff83287b93779061bf4e7a330df
The interpretation of BT NREC by AudioFlinger to enable
or disable AEC and NS was wrong: NREC to ON (default) means
the phone (Audio Gateway) must enable local AEC and NS.
Change-Id: I88a264e7fc9831c43bbace4f6b585baec73f2006
Do not call audio HAL functions on the primary HW interface
if it could not be initialized properly.
Change-Id: If54059c8fd188d6c1686f9e0439994fe9411478a
AudioManager.isWiredHeadsetOn() should not require permission MODIFY_AUDIO_SETTINGS.
Remove permission checks on all getters in audio policy manager as permission enforcement
is really usefull for setters.
Also deprecate AudioManager.isWiredHeadsetOn() which name and implementation are deceptive.
Change-Id: I38f8df7c26c0d417bf0e2b74e4c11c2d143f2ecd
Before this change, CPU and memory usage for an audio effect were
registered and checked against the limit by audio policy manager
upon effect instantiation. Even if an effect was not enabled
it would prevent another effect to be created if the CPU load budget
was exceeded, which was too restrictive.
This change adds a method to register/unregister CPU load only when
an effect is enabled or disabled.
It also adds a mechanism to place all effects on the global output mix
in suspend state (disabled) when an effect is enabled on a specific session.
This will allow applications using session effects to have the priority
over others using global effects.
Also fixes some issues with suspend/restore mechanism:
- avoid taking actions when an effect is disconnected and was not enabled.
- do not remove a session from the suspended sessions list when corresponding
effect chain is destroyed.
Change-Id: I5225278aba1ae13d0d0997bfe26a0c9fb46b17d3
Don't remove effects until the session they are in goes away or all
AudioEffects have been explicitly released. This allows the control
panel process to die without stopping the effects.
Change-Id: I4496e5df080230ca1af149dec95c1309ab8ea888
Some methods would not check that the output orinput stream of a thread
was still valid before calling functions on its interface.
This could cause a crash if those methods where called while the output or
input was being closed by another thread.
Make sure that the output or input stream pointer is cleared before closing the
stream.
Always check that the output or input pointer is not null before calling
functions at the stream interface.
Generalize the use of initCheck() method to verify that the output or input
stream is not null.
Change-Id: I9d9ca6b744d011bcf3a7bbacb4a581ac1477bfa5
Disable AEC and NS when the Bluetooth SCO headset in use indicates it
implements those pre processings.
Change-Id: I93f3d10b0a27243d5dbff7182639576fc0c6d862
Add the possibility for the effect framework to suspend
(temporarily disable process) and restore audio effects.
This feature will be usefull to disable pre processing under certain
conditions and better control coexistence of audio effects
on output mix and specific sources.
Change-Id: I79b195982cc48748d5708308fb1647b9c3c34cc6
If a pre processing effect is detroyed while enabled and capture is active,
there was a possibility that the effect engine is released by the framework
while still processed by the audio HAL.
The fix consists in not releasing the engine in EffectModule::removeHandle()
but just flag the effect as being detroyed to avoid further calls to functions
on the engine effect interface.
The effect interface is then removed from the audio HAL safely in
EffectChain::removeEffect_l() while holding the EffectChain mutex.
Change-Id: I71fab30d9145062af8644f545a1f1d4d3e7e7f02
The problem is that the audio HAL fails to acquire the wake lock when playing the notification.
This is because of a change that removed the mediaserver process form the system group for honeycomb.
The fix consists in requesting the wake lock from PowerManagerService when AudioFlinger mixer
wakes up.
A consequence of this change is that audio HALs or pcm drivers do not have to hold wake locks
anymore as in the past.
Change-Id: I4fb3cc84816c9c408ab7fec75886baf801e1ecb5
Added APIs to control pre processes applied on captured audio.
Those APIs are still hidden until reviewed by API council.
Three types of standard pre processes are supported:
- Automatic Gain Control (AGC) by AutomaticGainControl class
- Acoustic Echo Cancellation (AEC) by AcousticEchoCanceler class
- Noise Suppression (NS) by NoiseSuppressor class
A method is added to AudioEffect class to query audio pre processings
applied by default by the platform on a given AudioRecord session ID.
Change-Id: I0b9fceeb8c704dd06319c3b52b85c96fe871d51d
Dump of media.audio_flinger service was only listing effects on output threads.
Moved the dump of effect chains from PlaybackThread to ThreadBase class so that
pre processings on RecordThread are also listed.
Change-Id: If8bc74023c12b9c2371f1b300743b156ceca7b87
Audio effect framework is extended to suport effects on
output and input audio path.
AudioFlinger: Support for audio effects and effect chains is
moved from PlaybackThread class to ThreadBase class so that
RecordThread can manage effects.
Effects of type pre processing are allowed on record thread
only. When a pre processing is enabled, the effect interface handle is
passed down to the input stream so that the audio HAL can call the
process function. The record thread loop calls the effect chain process
function that will only manage the effect state and commands and skip the
process function.
AudioRecord: The audio session is allocated before calling getInput() into
audio policy serice so that the session is known before the input theead is
created and pre processings can be created on the correct session.
AudioPolicyService: default pre processing for a given input source are
loaded from audio_effects.conf file.
When an input is created, corresponding effects are created and enabled.
Change-Id: Id17119e0979b4dcf189b5c7957fec30dc3478790
Moved specific effect header files to
system/media/audio_effects/include/audio_effects
and renamed to lower case (effect_xxx.h).
Change-Id: Icfc2264bfd013cab0395d7e310ada636b9fe3621
Record and playback objects (resp AudioRecord and AudioTrack)
are created using a channel mask, but this information is lost
in the mixer because only the channel count is known to
AudioFlinger. A channel count can always be derived from a
channel mask.
The change consists in:
- disambiguiting variable names for channel masks and counts
- passing the mask information from the client to AudioFlinger
and the mixer.
- when using the DIRECT ouput, only verifying the format of
the track is compatible with the output's for PCM.
Change-Id: I50d87bfb7d7afcabdf5f12d4ab75ef3a54132c0e
Moved and renamed media/EffectApi.h to hardware/audio_effect.h
Modified the effect library API to expose a library info structure
containing an interface functions table.
Also removed enums for audio channels, audio format and devices
from effect API and use values from system/audio.h instead.
Modified effects factory to support new library interface format and
load libraries and efffects listed in audio_effects.conf file.
The file audio_effects.conf is first loaded from /vendor/etc and
then from /system/etc/audio_effects.conf if not found.
Modified existing effect libraries to implement the new library interface.
Change-Id: Ie52351e071b6d352fa2fbc06c3846686f8c45df9
