Could you please explain this fix a bit? Trying to understand this and please let me know if there is anything wrong. Here is my understanding flow:

1. The method where this piece of logic is at is getEncodingAndConfigForPassthrough(Format format), by which we query if the passed format is supported.
2. According to the code and comment, when it is a DTS:X P2 stream, the format passed-in may have a wrong ChannelCount=8 for some devices, then what is the expected channel count here? Here the logic allows any channel count <= 10 reported with the passed-in format to be supported, does it mean "for DTS:X P2, the channel count reported can be arbitrary"?

If the last question above is kind of a "yes", would it be possible to consider using getMaxSupportedChannelCountForPassthrough(encoding, sample)? The benefit of this is, for API >= 29, we can query directly from the platform if a channel count is supported for an encoding. Here is an example of the usage for Dolby object-based surround sound.

Please let me know how you think :)

The answer is yes. Ok, tomorrow I will try and see if I can use getMaxSupportedChannelCountForPassthrough :)

@tianyif Please see my latest commit aecc8dd for the change to use getMaxSupportedChannelCountForPassthrough(encoding, sample). So we don't really need to do
"if (format.sampleMimeType == MimeTypes.AUDIO_DTS_X) {
if (channelCount > 10) {" etc.

Thanks.

@tianyif I mis-intepreted the meaning of arbitrary to mean whether channelcount can be any value when using direct passthrough mode.
In this case, the platform has mistakenly reported max channel count as 8 for DTS:X P2. The correct maximum channel count should be 10. Therefore, I think is it better to stick to the original code that fixes this platform mistake. Please see commit 61a6b99. Thanks

Is there a issue on buganizer or any other issue ID we can add as a comment as to this? It's not uncommon we go back to pieces of code that have assumptions like this one, and having the ability to get more context helps.

Let's clarify this -

the platform has mistakenly reported max channel count as 8 for DTS:X P2

Does the "max channel count" above refer to the maxChannelCount in the method? That's the maxChannelCount property of the AudioCapabilities class. Looking at how we construct AudioCapabilities, I saw we just used DEFAULT_MAX_CHANNEL_COUNT=8 for most of the cases (only HDMI connection case can lead to a different value). Looks like the value of 8 becomes insufficient, and we should consider to refresh this value or add some flexibility to construct AudioCapabilities.

Is this corresponding to the issue you mentioned?

@tianyif Yes. It refers to maxChannelCount in the method. I mistakenly assumed that this came from the platform. If DEFAULT_MAX_CHANNEL_COUNT can be increased to 10, then this issue would be resolved. Thanks.

@tianyif Set AudioCapabilities.DEFAULT_MAX_CHANNEL_COUNT to 10. Please see a9274b9). Let me know if it is ok. Thanks

@tianyif This is the conversation that is related to the commit 78a0385 Thanks.

This change conflicts with an ongoing pull request from Dolby in which the case 10 will always return 5.1.4. I will consult with the platform team today what can happen (for SDK <= 31) when creating AudioTrack with channel count 5.1.4 for DTS:X P2 stream, or with channel count 7.1 for DD+JOC stream.

If there is any potential problem with that, I'm afraid that we should refactor this method getAudioTrackChannelConfig first to take the mime type into consideration.

Creating an AudioTrack for DTS:X P2 with AudioFormat.CHANNEL_OUT_5POINT1POINT4 (taking the integer value) will fail on MTK platforms. That is why I switched it to AudioFormat.CHANNEL_OUT_7POINT1_SURROUND for API <=31. :)

Acknowledged, we will discuss internally tomorrow on the potential refactorization of getAudioTrackChannelConfig. Thanks!

@tianyif Any updates on this? Thanks.

We got a hint from the audio framework team that the height channel masks were added in SDK 32 (e.g. CHANNEL_OUT_TOP_BACK_LEFT), so we are now reaching to Dolby to see AudioTrack creation with 5.1.4 will also fail for them when API <= 31. If that's the case, the conflicts won't be there. But we are also waiting for a concrete answer from audio framework team as well.