PCM channel count is limited to AudioSystem.CHANNEL_OUT_MAX.
Compressed channel count is limited to AudioSystem.FCC_24
as typically the data rate is smaller than the equivalent
PCM channel count stream.
Test: atest AudioTrackTest
Test: atest AudioTrackTest#testImmersiveStreaming
Test: atest AudioTrackTest#testImmersiveChannelIndex
Bug: 187062102
Change-Id: I96b2e37c9b59c9e38a0caf69e19c280949c4d099
Allows a device to specify a higher sample rate (e.g. 384kHz)
and have it acknowledged by CTS.
Test: AudioTrackTest#testGetMinBufferSizeTooHighSR
Bug: 135474352
Bug: 187062102
Change-Id: I2a44590970b437c1090c615961432afce974f2ba
Anticipate more than 8 channels (such as 7.1.4) on
future devices, but keep at 8 for now.
Test: atest AudioTrackTest#testImmersiveStreaming
Test: same test by manually adjusting to 24 channels.
Bug: 127896072
Bug: 187062102
Change-Id: I72c2ff0faa7794f22deaeb794920afb65788f40b
Also print a log when restore route to default while a bluetooth
route is avaialble.
Bug: 176386259
Test: build
Change-Id: I4a974438040595597fbf4dcb0ec57d49351540ef
Get multiple audio/video codec profiles from MediaProfiles object
instead of just wrapping the old CamcorderProfiles objects.
Bug: 171673898
Test: atest CamcorderProfileTest
Change-Id: If56ac6c2a89992361f0491d8175af1f89dffd3d0
Given that system usages were added to the AudioAttributes, system
components need to use the API were applicable. AudioMixingRule was
missing this and thus the audio attribute usage base routing did not
work correctly. In particular the registration of the audio policy mixing
rules would not register the system usages based routing correctly.
Instead, the match usage rule would default to unknown usage instead of
the requested system usage.
Bug: 186661937
Bug: 186442942
Bug: 186158497
Test: build gcar_emu_x86 and run car kitchen sink to make sure routing
performed as expected.
Change-Id: I4aaedf1b6b9144bd2e84d2d7112b5ebcf744a8b2
China DTMB digital TV.
See SJ/T11368-2006
“Specification for multichannel digital audio coding technology”.
Test: atest AudioFormatTest
Bug: 185950819
Merged-In: Id6078e65941020a73f8a43017f480574c2a78999
Change-Id: Id6078e65941020a73f8a43017f480574c2a78999
The test failed for several reasons:
- When other real cast device is present, tests are run before actual
routes arrive.
- Screen is not turned on during test.
- Test lacks MEDIA_CONTENT_CONTROL permission.
This CL fixes the test.
Bug: 186190171
Test: atest com.android.mediaroutertest.MediaRouter2ManagerTest \
--rerun-until-failure
Change-Id: I6f86ae7cba25871ffb7c8ee96f4c8db6bd86b816
Playing status of audio source is checked using the native handler
not 0.
However, if AudioSystem#startAudioSource fails, the native handler
returned is not 0, but an error code.
In fact AudioPolicyManager sets the PORT to NONE (0) and sets an error
status.
JNI layer transforms the failure status into a native handler returned
to the caller.
Signed-off-by: Francois Gaffie <francois.gaffie@renault.com>
Change-Id: Iaa920c073885c2556a93a1b5ae23467fa6ffad4f
Merged-In: Iaa920c073885c2556a93a1b5ae23467fa6ffad4f
Playing status of audio source is checked using the native handler
not 0.
However, if AudioSystem#startAudioSource fails, the native handler
returned is not 0, but an error code.
In fact AudioPolicyManager sets the PORT to NONE (0) and sets an error
status.
JNI layer transforms the failure status into a native handler returned
to the caller.
Bug: 186088557
Test: make
Signed-off-by: Francois Gaffie <francois.gaffie@renault.com>
Change-Id: Iaa920c073885c2556a93a1b5ae23467fa6ffad4f
New API to add/remove a listener for changes to the audio
mode (see existing AudioManager.getMode() API).
Bug: 184891081
Test: atest android.media.cts.AudioModeListenerTest
Change-Id: I0be07d577c7497066b61a1573752343227605fd7
Add the possibility for privileged applications to
share part of their audio capture history with another app.
A privileged app with permission CAPTURE_AUDIO_HOTWORD can share part of
its recent capture history on a given AudioRecord with the following
steps:
1) Specify the maximum time in the past that will be available for other
apps by calling setMaxSharedAudioHistoryMillis() on the AudioRecord.Builder
when creating the AudioRecord
2) Start recording and determine where the other app should start
capturing in the past.
3) Call AudioRecord.shareAudioHistory() with the package name of the app the history
will be shared with and the intended start time for this app's capture relative to
this AudioRecord's start time.
4) Communicate the MediaSyncEvent returned by shareAudioHistory() to the other app
5) The other app will use the MediaSyncEvent when creating its AudioRecord by calling
setSharedAudioEvent() on the AudioRecord.Builder.
6) Only after the other app has started capturing can this app stop capturing and
release its AudioRecord.
Bug: 183705547
Test: regression on capture use cases
Change-Id: I5beba6c1e489148a14ba86165b8ef2fdc78c802a
China DTMB digital TV.
See SJ/T11368-2006
“Specification for multichannel digital audio coding technology”.
Test: atest AudioFormatTest
Bug: 185950819
Change-Id: Id6078e65941020a73f8a43017f480574c2a78999
