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
Always read and write track volumes atomically. In most places this was
already being done, but there were a couple places where the left and
right channels were read independently.
Changed constant MAX_GAIN_INT to be a uint32_t instead of a float.
It is always used as a uint32_t in comparisons and assignments.
Use MAX_GAIN_INT in more places.
Now that volume is always accessed atomically, removed the union
and alias for uint16_t volume[2], and kept only volumeLR.
Removed volatile as it's meaningless.
In AudioFlinger, clamp the track volumes read from shared memory
before applying master and stream volume.
Change-Id: If65e2b27e5bc3db5bf75540479843041b58433f0
Improve volume management by keeping track of volume for each type
of device independently.
Volume for each stream (MUSIC, RINGTONE, VOICE_CALL...) is now maintained
per device.
The main changes are:
- AudioService now keeps tracks of stream volumes per device:
volume indexes are kept in a HashMap < device , index>.
active device is queried from policy manager when a volume change request
is received
initalization, mute and unmute happen on all device simultaneously
- Settings: suffixes is added to volume keys to store each device
volume independently.
- AudioSystem/AudioPolicyService/AudioPolicyInterface: added a device argument
to setStreamVolumeIndex() and getStreamVolumeIndex() to address each
device independently.
- AudioPolicyManagerBase: keep track of stream volumes for each device
and apply volume according to current device selection.
Change-Id: I61ef1c45caadca04d16363bca4140e0f81901b3f
A bad parameter to AudioFlinger::createTrack could cause mediaserver to crash.
Other AudioFlinger stream type cleanup:
- Simplify range check for audio_stream_type_t
- Add comment about mStreamTypes array initialization.
Change-Id: Ia33aa1cce0fdd694b08d9288816ffc097a9543d0
mMasterVolume and mMute are both protected by mutex in AudioFlinger class, but
there were two places where they were accessed without a mutex.
Also make AudioFlinger::mMasterMute private not protected.
Change-Id: Ia3897daeb5c50313df5bcc071824357526237f3e
Add an API to control block for getting/setting send level.
This allow us to make the mSendLevel field private.
Document the lack of barriers.
Use 0.0f to initialize floating-point values (for doc only).
Change-Id: I59f83b00adeb89eeee227e7648625d9a835be7a4
except in the control block, where we don't have room.
In AudioFlinger::ThreadBase::TrackBase::getBuffer,
read the frame size from control block only once.
Change-Id: Id6c4bccd4ed3e07d91df6bbea43bae45524f9f4e
At native level it was a mixture of audio_stream_type_t, int, uint32_t,
and uint8_t. Java is still int. Also fixed a couple of hard-coded -1
instead of AUDIO_STREAM_DEFAULT, and in startToneCommand a hard-coded 0
instead of AUDIO_STREAM_VOICE_CALL.
Change-Id: Ia33bfd70edca8c2daec9052984b369cd8eee2a83
AudioSystem::setMode previously allowed negative modes, but these were
then rejected by AudioFlinger.
Now negative modes (including AUDIO_MODE_INVALID and AUDIO_MODE_CURRENT)
are explicitly disallowed.
Change-Id: I0bac8fea737c8eb1f5b6afbb893e48739f88d745
AutoMutex, which is a typedef for Mutex::Autolock, is overloaded for
either a reference (&) or pointer (*) parameter, but we prefer to use
the reference form when the mutex is known at compile time.
Change-Id: I3515e6d6ab7959b2356a27fa3b04fd49e42cb31e
Using the builtin is faster on some platforms, for example on ARM it's
19 instructions instead of 13, and is O(1) instead of O(n). Of course,
track creation is an inherently slow operation, so this doesn't matter
much now. But if we add support for virtual tracks, then physical tracks
will be allocated/freed more frequently. Also just on principle ...
Change-Id: I3f590934092bd7a1869cbedbc7357928aa5cc8ff
Several source files privately defined macros LIKELY and UNLIKELY in terms
of __builtin_expect. But <cutils/compiler.h> already has CC_LIKELY and
CC_UNLIKELY which are intended for this purpose. So rename the private
uses to use the standard names.
In addition, AudioFlinger was relying on the macro expanding to extra ( ).
Change-Id: I2494e087a0c0cac0ac998335f5e9c8ad02955873
