Dev v2 is direct playback supported #6500
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @andrewlewis, can you share your feedback on this request? Android 10 supports MSD (intermediate module) audio HALs and their audio output capabilities can be queried via the isDirectPlaybackSupported APIs. |
|
Is there anything I can do to assist the review of this pull request? |
|
@dwhea Sorry for being so slow to respond! Due to the Coronavirus lockdown we don't have lab equipment for testing encoded audio passthrough (direct playback), and I'd like to test this out manually before proceeding, so please expect further delay. I'm also curious how the behavior of the |
|
@andrewlewis isDirectPlaybackSupported is a non-device specific API to check "can the system playback this encoding"? It is applicable to other device types, like Speaker and Headphone, not just HDMI. For products with MSD audio HALs exposed via BUS audio device types, the API allows for AudioTrack playback capability (e.g. even if the Primary Audio HAL format is PCM, if the MSD supports DD+, then the isDirectPlaybackSupported API returns true allowing for the DD+ AudioTrack to play). My understanding is there is a limitation in the current audio framework whereby MSD audio profiles that are declared as attached BUS devices in the product's audio policy are not resolved / reported by the AudioDeviceInfo API. The isDirectPlaybackSupported on the other hand does work for such MSD products. The API maps to AudioPolicyManager https://cs.android.com/android/platform/superproject/+/master:frameworks/av/services/audiopolicy/managerdefault/AudioPolicyManager.cpp;l=3253?q=isDirectOutputSupported&ss=android In short, this new API should return a superset of the capabilities reported by HDMI hot plug encodings. |
|
Hi @andrewlewis : do you have any updates on this topic? |
andrewlewis
reviewed
Nov 30, 2020
| for (int e : possibleEncodings) { | ||
| if (AudioTrack.isDirectPlaybackSupported( | ||
| new AudioFormat.Builder() | ||
| .setChannelMask(AudioFormat.CHANNEL_OUT_STEREO) |
There was a problem hiding this comment.
Do you know if the channel mask (and sample rate) are taken into account, or are they ignored?
Based on the marketing info MS12 here I guess they aren't relevant because the MS12 decoder will convert the incoming audio (in any format) into one suitable for the current output capabilities, but I wanted to check in case you know otherwise.
There was a problem hiding this comment.
The audio framework requires channel mask and sample rate matching for direct outputs (it's searching for a compatible IOProfile and channel mask & sample rate are some of the parameters required to match). Checking only stereo / 48 kHz is not a complete solution, but is on par with the current AudioCapabilities.java implementation which is only checking for format support; this PS rests on the assumption that most direct outputs will support stereo / 48 kHz for all formats, and using stereo / 48 kHz is sufficient to extract the direct output format capabilities. A larger change in ExoPlayer checking for sample rate / channel mask matching is out of scope of this PS.
For MS12, all Dolby decoder (e.g. Dolby Digital Plus) implementations support all respective codec sample rates, and will decode to the current output capabilities.
andrewlewis
reviewed
Nov 30, 2020
| @@ -34,6 +34,7 @@ | |||
| android:banner="@drawable/ic_banner" | |||
| android:largeHeap="true" | |||
| android:allowBackup="false" | |||
| android:usesCleartextTraffic="true" | |||
There was a problem hiding this comment.
If we proceed with this pull request, I think the cleartext traffic and media.exolist changes should be reverted.
There was a problem hiding this comment.
Please could you revert these files and synch to dev-v2 HEAD and we can try to get this merged. Thanks!
|
I heard there is a Dolby SDK that allows querying and controlling MS12 functionality. Do you know whether it's possible to write a proper integration with direct playback without access to that SDK? Generally, I'm just a bit concerned we'd see regressions from API 29 if we merge this, as I haven't ever used this API and we don't have testing equipment to validate the change doesn't break things that currently work. I'm inclined to say we should wait until we have access to testing equipment so we can be confident that this works as expected and avoids regressions. Until then, apps can implement this functionality themselves by creating |
|
Re: #6500 (comment) The Dolby SDK is not required for checking direct playback capability. |
@dwhea If you have access to it, please could you provide some information on what other functionality the SDK does provide that might be useful to apps using direct output? |
andrewlewis
reviewed
Jun 4, 2021
|
|
||
| @TargetApi(29) | ||
| private static int[] getDirectPlaybackSupportedEncodings() { | ||
| int[] possibleEncodings = new int[]{ |
There was a problem hiding this comment.
For now, could we restrict this to the useful subset that's compatible with DefaultAudioSink, which consists of the encodings AC3, E_AC3, E_AC3_JOC, AC4, DOLBY_TRUEHD, DTS, DTS_HD and PCM_16BIT?
Later on we can investigate making this class not immutable and having supportsEncoding call through directly to the platform so we don't need to worry about listing them exhaustively but that is beyond the scope of this change.
For Q devices and higher, use AudioTrack.isDirectPlaybackSupported for determining AudioCapabilities.
dwhea
force-pushed
the
dev-v2-isDirectPlaybackSupported
branch
from
a54df29
to
cb1084f
Compare
icbaker
pushed a commit
that referenced
this pull request
Jul 21, 2021
…ckSupported PiperOrigin-RevId: 378895355
|
@dwhea There was a report that these changes caused a regression in #9239. The issue seems to be that |
|
@andrewlewis the isDirectPlaybackSupported current implementation checks for 48 kHz sample rate capabilities, yet the #9239 is attempting to open 44.1 kHz: does this mismatch explain the AudioTrack create failure? What does the device audio policy (adb shell dumpsys media.audio_policy) report before playback fails? NOTE: encodings for OFFLOAD and DIRECT can overlap on devices. Such devices, such as STBs, can report HDMI pass-through as DIRECT, but also on-device decoding (and HW processing before transmit over HDMI) as OFFLOAD. The intent of the current implementation in ExoPlayer is for the compressed audio track support to check both OFFLOAD and DIRECT, and this is satisfied by the isDirectPlaybackSupported check. |
|
In ExoPlayer code I think we need to be able to tell the difference between passthrough and offload mode, because (for example) the Is there any reason for a TV device/STB to support offload? I thought the only use case was for power saving on mobile devices, which doesn't seem applicable for TVs, hence the workaround that only uses this method on TV devices.
I'm not sure but based on the dumpsys these encodings only seem to be supported by the adb shell dumpsys media.audio_policy |
|
TV device / STB may support offload for HW codec processing / audio pipelines. An example of this is the TCL 55T8S TV, which shows the E_AC3 and AC4 codecs available via OFFLOAD path: TCL 55T8S TV audio policy dumpsysHW Modules dump: - HW Module 1: - name: primary - handle: 10 - version: 3.0 - outputs: output 0: - name: primary output - Profiles: Profile 0: - format: AUDIO_FORMAT_PCM_16_BIT - sampling rates:44100, 48000 - channel masks:0x0003 - flags: 0x0002 (AUDIO_OUTPUT_FLAG_PRIMARY) - Supported devices: Device 1: - id: 2 - tag name: Speaker - type: AUDIO_DEVICE_OUT_SPEAKER Device 2: - tag name: Wired Headset - type: AUDIO_DEVICE_OUT_WIRED_HEADSET Device 3: - tag name: Wired Headphones - type: AUDIO_DEVICE_OUT_WIRED_HEADPHONE Device 4: - tag name: HDMI Out - type: AUDIO_DEVICE_OUT_AUX_DIGITAL Device 5: - tag name: HDMI Arc - type: AUDIO_DEVICE_OUT_HDMI_ARC |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.