This code has null checks with intervening unconditional dereferences of
the potentially-null variable.
It's not clear that `mOutput` can ever be null to begin with. If it can
be, we have a few dereferences to guard. :)
Caught by the static analyzer:
frameworks/av/services/audioflinger/Threads.cpp:2671:19: warning: Called
C++ object pointer is null [clang-analyzer-core.CallAndMessage]
frameworks/av/services/audioflinger/Threads.cpp:2852:9: warning: Called
C++ object pointer is null [clang-analyzer-core.CallAndMessage]
Bug: None
Test: TreeHugger
Change-Id: I456581204718390088998a1fe2514dff63f6578f
The logic in IOProfile::devicesSupportEncodedFormats()
was only checking if the first device in the list of supported devices
was supporting currently selected A2DP encoding format.
But if more than one devices match the queried types, we need to check
all devices in case one of them supports the selected encoding format.
Bug: 147789166
Test: repro steps in the bug.
Change-Id: I704c5c6278eed524f15e7b73cec68a24f04d3a8c
Extend MONO_HACK to multi-channel output.
Mono track will have only one channel output on multi-channel devices.
Since ARC++ exposed a 4-channel output device and downmix track in
ChromeOS, we need to add this feature to support mono track sample
expansion.
Add support for both re-sample and non-resample path.
For resample path, we need to add MIXTYPE_STEREOEXPAND in
AudioMixerOps.h since AudioResampler will upmix mono track to stereo
track.
Bug: 120222604
Bug: 112341269
Bug: 117116052
Bug: crbug.com/890560
Test: Play mono tracks without re-sampling on ARC++
Test: Play mono tracks with re-sampling on ARC++
Test: Play normal stereo tracks on ARC++
(cherry picked from commit 9b79e0752e6536c31430aa31838a9de1b7b56f9f)
Change-Id: I51f5914c41dd0196db9c6a2e1a99b44e5d87c0d6
CrOS exposes 4-channel output for ARC++ and mixes samples in CRAS
server to real channel format, but AudioMixer will discard right
channel volume when mixing a 2-channel track to 4-channel output.
This behavior will cause ARC++ fail on Audio Frequency Line Test
in CTS-V since the right channel can't be tested.
The code is also updated to work for 3, 5, 6, 7, 8 canonical output
channel position masks, as well as continue the mono volume
handling for output channel index masks.
Bug: 110551766
Test: Run CTS-V Audio Frequency Line Test
Test: atest mixerops_benchmark
Change-Id: I4c6ee86d30bb8296f0e32f9a17b1135e1313fd64
SharedRefBase now encapsulates heap allocation in order to guard against
some types of double-ownership.
Bug: 149249948
Test: TH
Change-Id: Ida943c895225331a853e4c8da54454d60b17000a
Add meteric to show the difference between drm
playback of protected vs unprotected content.
We log onQueueInputBuffer errors.
Bug: 138862395
Test: adb shell dumpsys media.metrics | grep -i InputBuffer
Change-Id: I26aae706267956b6f944955877347747e573e3c8
Methods like reconfigureCamera called by the RequestThread internally
call methods which might expect to have mInterfaceLock locked
(eg: configureStreamsLocked).
Also, function calls which expect to be serialized w.r.t
reconfigureCamera can cause reported camera status to be inconsistent
w.r.t the expected status.
For example the following situation might occur
through CameraTest.java#testVideoSnapshot :
For certain video sizes that would fail to configure the camera
startRecordingL
camera reconfiguration is triggered -> reconfigureCamera() starts
waitUntilDrained -> gets interleaved with reconfigureCamera()
reconfigureCamera() completes
Here the status of the camera device is active instead of CONFIGURED.
updateRecording
createStream() called expects the camera to not be in an ACTIVE
state since updateProcessorStream cannot handle stream
configuration failure gracefully when the device is streaming.
However since waitUntilDrained did not complete after
reconfigureCamera the camera status is STATUS_ACTIVE.
As a result, we should hold mInterfaceMutex while
calling these methods. To avoid deadlocks (b/143513518), we can have the thread
calling disconnect, relinquish mInterfaceMutex right before it starts
waiting on RequestThread to exit. It can re-acquire it when
RequestThread finishes.
Bug: 147313521
Test: atest CameraTest.java#testVideoSnapshot on pixel2 passes
Test: camera CTS
Test: GCA (sanity)
Change-Id: I384f62bc9936d9691dfe9c13ff743e3d07f2ed55
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
am skip reason: Change-Id Id67dc9e793ee886e4cc49370d800c7f3580df313 with SHA-1 9c930d0cac is in history
Change-Id: I9495b79433ed85e141d8b413c0c86aba66513550
am skip reason: Change-Id Icdfe5a823ba02eb7bd8c41f0fa503c9922d8f348 with SHA-1 ea51ad6e1d is in history
Change-Id: I4b1aaa3714d99c12739fba8076318b151b2e629c