mirror of
https://github.com/androidx/media.git
synced 2025-05-06 23:20:42 +08:00
8c8176647c
Background: 1. When the player has multiple audio renderers, by default they share a single AudioSink. 2. When any new renderer is enabled, all disabled renderers are reset prior to the new renderer being enabled. This is to give them a chance to free up resources in case the renderer being enabled needs them. These reset calls are expected to be no-ops for renderers that have never been enabled. The issue: The problematic case arises when there are two audio renderers and a third renderer (e.g., text) is being enabled. In this case, the disabled audio renderer's reset call ends up resetting the AudioSink that's shared with the enabled audio renderer. The enabled audio renderer is then unable to make progress, causing playback to freeze. This is a minimal fix that directly prevents the mentioned issue. There are multiple follow-ups that would probably make sense: 1. Having ExoPlayerImplInternal track which renderers need to be reset, and only resetting those renderers rather than all that are disabled. This seems like a good thing to do regardless, rather than relying on those calls being no-ops. 2. If we want to continue sharing AudioSink, we need to formalize this much better and make sure we have good test coverage. Messages like MSG_SET_VOLUME are also delivered to the AudioSink multiple times via each of the renderers, which works currently because DefaultAudioSink no-ops all but the first call in each case. This is pretty fragile though! Issue: #8203 #minor-release PiperOrigin-RevId: 343296081
ExoPlayer library
The ExoPlayer library is split into multiple modules. See ExoPlayer's top level README for more information about the available library modules and how to use them.