On Shield Experience 8.x (API 28) ExoPlayer force-decoded TrueHD to
multi-channel PCM, and enabling passthrough on the mpv backend made every
non-AAC file wedge on an infinite buffering spinner with no audio pipeline
at all.
Two defects behind one symptom pair:
- The MAT/DTS-HD carrier oracle stopped at API 29 because
AudioTrack.isDirectPlaybackSupported does not exist below it, so API 24-28
never offered the carrier even on routes that genuinely bitstream it. Below
API 29 the HDMI AudioDeviceInfo is the only vouching signal, so the carrier
is now offered when an HDMI output explicitly advertises IEC 61937 at
192kHz/8ch; unspecified (empty) capability arrays deliberately do not
count, because an unvouched IEC track that initialises without being
bitstreamed renders as full-scale noise. A route that advertises and still
refuses the track fails AudioTrack init into the existing force-decode
recovery.
- The mpv audio-spdif list was gated on the raw encodings the route
advertises, but mpv's audiotrack AO opens every spdif format as a stereo
ENCODING_IEC61937 track clamped to the 48kHz mixer rate. E-AC3, TrueHD and
DTS-HD MA structurally cannot survive that shape, and a route can advertise
raw encodings while its HAL takes no IEC track at all - naming any codec
there leaves mpv's audio chain stuck before AO init (reproduced on a Shield:
spdif_ac3 selected, no AudioTrack ever opened, playback never starts). The
list is now capped to ac3,dts and additionally gated on the route accepting
the stereo IEC shape, using the same tiered oracle as the carrier. The
primary mpv backend previously wrote a hardcoded five-codec list from Dart;
it now asks the plugin to derive the value from the audio route, like the
ExoPlayer fallback already did.
Verified on a Shield (API 30) with a full-capability EDID: TrueHD rides the
carrier and survives speed transitions (instrumentation), and an E-AC3 title
that previously wedged under mpv+passthrough now decodes and plays with
audio-spdif=ac3,dts.
close#1991
edde746
c5e7ce648b