Compute summary statistics based on the current device
rather than the entire AudioTrack or AudioRecord duration.
Test: adb shell dumpsys media.metrics
Bug: 149850236
Change-Id: Ia3a5707c43c4530f5a6ac90f52901bd2e0bd0bab
Also add track state name helper function for logging.
Test: Play video clip then pause and resume several times
Bug: 145613591
Change-Id: If4fc2565da9b3d4964fb9fdb6f5854ff6fbadfb8
Capturing from source AUDIO_SOURCE_FM_TUNER is possible only via @SystemApi
on one end and does not capture from an actual on the other end.
Accordingly, do not check android.permission.RECORD_AUDIO anymore but
check privileged permission android.permission.CAPTURE_AUDIO_OUTPUT instead.
Also bypass App Ops OP_RECORD_AUDIO check which is applicable only to capture from
microphones.
Also fix audio recording permission check in MediaRecordClient to use
recordingAllowed() from ServiceUtilities
Bug: 135717621
Test: CTS tests for AudioRecord
Change-Id: Ibb1d72f018d2e3ceee195338f2e262183eee2a23
There were three issues with the implementation
of Audio Playback Capture patches on secondary outputs.
1) Patch tracks were always forced to be ready, even if there were not
enough audio to be played. That led to playing partial buffers if the
source output had smaller (time wise) buffer than the secondary output.
This is fixed by avoiding setting CBLK_FORCEREADY on every buffer push
from the primary output thread.
2) After 1 is fixed, the patch tracks now behave like regular (non fast)
tracks. This means that the track only starts when it is full.
That leads to overrun on startup as the primary and secondary outputs
usually do not have the same write period.
What makes the issue worst is that Remote submix has a fixed buffer in bytes,
so its write period changes depending on sample rate contrary to the
primary HAL which pulls with fixed time periods (usually 20/40ms).
This patch solution is to introduce a ready threshold. The track will be
considered ready to be active if there are more than frames in its buffer.
To avoid changing previous latency behaviour except for APC,
legacy tracks have this threshold set to their buffer size and
non APC patch tracks have it set to 1, similar to setting
CBLK_FORCEREADY.
3) The patch track buffer size calculation of the patch track did not take
into account primary and secondary output could be of different sampling
rate.
This mean that the patch track buffer was usually too small as the
secondary output usually had smaller sampling rate (Live caption
requests 16kHz) than the track (music usually plays in 48kHz).
This made the two problems even worst.
This was easily fixed by scaling the buffer size with each side sample rate.
Bug: 136691300
Test: play audio
adb shell audiorecorder --target /data/file1.raw
# Check that the recorded file has no underrun
Change-Id: Ib2846b2827afd1b953d4a25acb18c7cadf57cd3e
Signed-off-by: Kevin Rocard <krocard@google.com>
Properly handle 'timeOut == nullptr' case in
PassthruPatchRecord::obtainBuffer.
Bug: 117564323
Test: make
Change-Id: Id352e47682c0992b817f26b3b594ec5913e663be
Implement a subclass of PatchRecord that uses PatchTrack's
thread for reading from HAL. This eliminates the need for
buffering that adds latency.
The only modification needed for PatchTrack is to indicate
unlimited amount of available frames to the playback thread.
This is to prevent PatchTrack from being deactivated by
DirectOutputThread due to lack of frames available.
RecordThread believes it reads audio data on its thread,
and manages timestamps as usual. The data that it "reads"
and passes to PassthruPatchRecord is discarded by the latter.
Bug: 117564323
Test: MS12 MSD, AOSP MSD
Change-Id: I376656e3c791e91e2196331ecdf2b425697c4e18
This code logically belongs to PatchRecord because it emulates
obtaining recorded data from a client.
Test: make
Change-Id: Icba4e33d9d0ca57e6ad964aaf3209e7db766f284
This change renames the IMemory raw pointer accessors to
unsecure*() to make it apparent to coders and code reviewers
that the returned buffer may potentially be shared with
untrusted processes, who may, after the fact, attempt to
read and/or modify the contents. This may lead to hard to
find security bugs and hopefully the rename makes it harder
to forget.
The change also attempts to fix all the callsites to make
everything build correctly, but in the processes, wherever the
callsite code was not obviously secure, I added a TODO requesting
the owners to either document why it's secure or to change the
code. Apologies in advance to the owners if there are some false
positives here - I don't have enough context to reason about all
the different callsites.
Test: Completely syntactic change. Made sure code still builds.
Change-Id: I5fb99aa797c488406083178a6b05355d98710d3b
Seeing requested / obtained buffer frame counts in trace
helps to identify discontinuities in software patch pipeline.
There is no need to trace requested frame count for PatchRecord
as it always requests as much as possible ("-1" frameCount).
Bug: 117564323
Test: with software patch active,
external/chromium-trace/systrace.py audio
Change-Id: I78400f6cc1d1940b3290fb23bb1aacfbffe042e5
Fix issue where RecordTrack silencing didn't silence the
full buffer: the memset to 0 was using the RecordThread frame
size, not the RecordTrack frame size.
OP_RECORD_AUDIO was only enforced at the start of a recording
which would fail if not granted. This patch silences the recording
(i.e. silence is recorded instead) when it is lost, and undoes that
when granted again. This requires:
- propagating the package name of the client to the RecordTrack class
- registering an appOp callback in RecordTrack (through a new
OpRecordAudioMonitor class) to (un)silence the recording
- update the isSilenced() method to take into account the appOp.
Bug: 138968594
Test: run app that records audio, then "adb shell appops __pack_name__ 27 2"
and verify recording is silent after that.
Change-Id: Ib33f5b592185a67204997213bab1ac2594d90d37
Do not check app ops for audio playback for services in
general, not just for audioserver or root user.
Bug: 133178934
Test: audio smoke tests
Change-Id: I3a34e6418dc750cc12ed35d465ca8874b0ce0f73
commit 74e01fa7 did not bypass app ops policy when flag
AUDIO_FLAG_BYPASS_INTERRUPTION_POLICY is set.
Bug: 131873101
Test: repro steps in bug
Change-Id: Idbce26cfdcddbb7a2ae8702ce3d135ef5a69f047
Do not force audio device changed callback when the client
(AudioTrack or AudioRecord) registers to AudioFlinger but only when
it starts playback or capture. Doing so prevents a spurious callback
happing at registration time where a stale device
(previously selected by AudioFlinger thread) but irrelevant to this
client is indicated. This causes a disconnection of AAudio streams
despite no real device change.
Bug: 128630993
Test: CTS: android.nativemedia.aaudio.AAudioTests, android.media.cts.RoutingTest
CTS Verifier: Audio Input/Output Routing Notifications Test
Change-Id: Ia7f1d11490989b0287c97479466c1c07a223aab3
OpPlayAudioMonitor was constructing a weak pointer to itself
in the constructor. This practice can lead to crashes due to
race conditions vs object destruction. This code is now moved
to onFirstRef method which is called when at least one strong
reference exists.
This change also reduces the number of created OpPlayAudioMonitor
objects by using a factory method.
Bug: 130038586
Test: enable / disable DND mode
Change-Id: I22e63a883ebaa25b9c96e79271bb9693b5ed75cd
Remove effect specific mutex (mEffectLock) in AudioPolicyService: Due to
concurrent capture (among other reasons), it is necessary that the audio
policy manager state preserved by mLock includes audio effects
registration and enabling.
Moved all audio policy API calls from audio flinger out of locked regions
for audio flinger, thread and effects mutexes to avoid cross deadlocks
between audioflinger and audio policy manager:
- centralized audio policy API calls in EffectModule::updatePolicyState()
- the enabled state now reflects the state requested by the controlling
handle, not the actual effect processing state: a suspended effect is
now considered enabled.
A new audio policy manager API moveEffectsToIo() is added to atomically
handle moving effects to a new input or output without having to call
unregister > register > enable sequence.
Also fix assert in setStreamVolume to match volume group refactoring
in audio policy manager.
Bug: 128419018
Test: CTS tests for audio effects.
Test: manual tests with Duo calls, Play Music, Youtube, notifications
with and without Bluetooth and wired headset.
Change-Id: I8bd3af81026c55b6be283b3a9b41fe4998e060fd
Mute/unmute tracks according to changes in OP_PLAY_AUDIO for
the current usage.
In audio policy: always assign AUDIO_STREAM_ENFORCED_AUDIBLE
to sonification tracks with AUDIBILITY_ENFORCED flag.
Do not mute tracks from root / audio server.
Do not mute UI sounds on AUDIO_STREAM_ENFORCED_AUDIBLE
stream type.
Bug: 112339570
Test: enter DnD, play notifications, verify not heard
Change-Id: Ia5f1118481cf0573101acf2092fbd0ce2cf8c038
This was not efficient and leaded to an assert in obtainBuffer.
I'm not sure which condition can lead to a getNextBuffer of size 0,
but it has been observed and is not forbidden by getNextBuffer
documentation.
Test: atest android.media.cts.AudioPlaybackCaptureTest#testCaptureMediaUsage
Bug: 111453086
Change-Id: I5accf7c1d488ff4686272588329bab71d64f67cd
Signed-off-by: Kevin Rocard <krocard@google.com>
Track::interceptBuffer failed to write all the audio if the source BP
could not returned the requested buffer size.
This is actually normal when the source circular buffer wraps around.
Handle it by retrying if the first buffer is too small.
Test: adb shell audiorecorder --target /data/file.raw
Bug: 111453086
Change-Id: I42a7962449a0f075909a29f5f8f5ba82ca1d0085
The secondary are returned from mixes (from DAP loopback&render),
from getOutputForAttr.
All getOutputForAttr* of the stack are update.
Internal getOutputForAttr use descriptor, external one use handles.
The secondary output are saved in each track and the track is
invalidated if the list of secondary output changes.
In audio flinger, create a pair of recordTrack & patchTrack to pipe
the intercepted audio audio to the secondary output.
Test: adb shell audiorecorder --target /data/file.raw
Bug: 111453086
Change-Id: Id6523d9e383c15a0e39313d5f355df809b7e72fe
Add support for timeout that was only supported by PatchRecord.
This is implemented by moving the timeout and common code in a base
class.
Also remove PatchRecord useless virtual inheritance of RecordTrack.
Test: adb shell audiorecorder --target /data/file.raw
Bug: 111453086
Change-Id: I833148f31a311ca41092be1d7e2d170f086322c5
Signed-off-by: Kevin Rocard <krocard@google.com>
The haptic playback should be controlled by vibrator service. Via the
interface, audio server could notify vibrator service about starting or
stopping haptic playback and get vibrator intensity from vibrator
service. Vibrator service could call mute/unmute to control the haptic
playback.
Test: Manually
Change-Id: Iad24813977e4dea0d67a91f8f8b390a016ce4ca2
Return the port ID allocated by audio policy manager instead of the
internal track ID allocated by audio flinger when an AudioTrack or
AudioRecord is created.
This information is more useful for logs and allows to associate information coming
from audiopolicy manager with a specific client instance.
Bug: 111438757
Test: Manual playback and capture tests
Change-Id: Ib467d8fcc34d9a8aa7bcaac0770a741982b847c5
The Java AudioTrack interface has a setPresentation API. This
calls the setParameters API in IAudioTrack. However, this does
not eventuate into a call into the android.hardware.audio@4.0
IStreamOut selectPresentation API.
Add selectPresentation API to IAudioTrack and call down to the
android.hardware.audio@4.0 IStreamOut selectPresentation API.
Translate into calls to setParameters API for legacy HAL
interfaces.
Bug: 63901775
Test: compile
Change-Id: Id634a107f3f93ab18dc80d2bd0af67bda35e859f
Handle spurious wakeups in stop.
Handle track invalidation.
Clarify state.
Note: start and stop should not be called simultaneously from different
binder threads.
Test: audio sanity
Bug: 117303225
Change-Id: I587d9cda7b0eac5215eb6a88f93ee08e396e3ef9
Add FALLTHROUGH_INTENDED for clang compiler.
Bug: 112564944
Test: build with global -Wimplicit-fallthrough.
Change-Id: I8875bc7ed073aae84d5df97eb39c8c745ca627ef
This relies on being able to obtain presentation position and
capture position accurately from the HAL, in the presence
of potential underruns or overruns.
Test: MSD hal dumpsys
Bug: 112428710
Change-Id: I9aad574baaff60b5e0c5d8c39a2147d19ee613f5
Test: Check AudioFlinger dumpsys during MSD direct record
Bug: 112388863
Change-Id: Id404c70af0c0e23a1e349522568b20f50573b1e9
(cherry picked from commit 2ceaf3dee96d1696b315afdee9ffc0df662f88d8)
Refactor audio policy service APIs controlling audio playback (startOutput, stopOutput, releaseOutput)
To allow finer grain control per AudioTrack client.
Test: AudioTrack CTS test. manual test of playback use cases.
Change-Id: I49a681f3c2a8211e524824993049b24d8086376d
When piping encoded audio data via software patch, it needs
to be created without the buffer converter. In this case the audio
data is copied directly from ResamplerBufferProvider.
Added input flag AUDIO_INPUT_FLAG_DIRECT to indicate to PatchPanel
that the PatchRecord track needs to be opened in this mode.
This flag can be later added to minor Audio HAL update.
Bug: 63901775
Test: MSD scenario; verified that phone over USB headset still works
on marlin / sailfish
Change-Id: If2745778d356769b143fb3c29910275ddef119ac