Tunneling playback intermittent crash: `MediaCodecVideoRenderer.onEnabled()` sees `tunnelingAudioSessionId == AUDIO_SESSION_ID_UNSET`

[zingergarfield]

Version

Media3 1.9.2

More version details

• Media3: 1.9.2
• Also relevant release-note note introduced in 1.6.0: Initial audio session id is no longer immediately available after creating the player.

Devices that reproduce the issue

Android STB with os 14 or os 11, which supports tunneling playback.

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

Enable tunneling playback, and play demo dash stream.

TrackSelectionParameters parameters = new DefaultTrackSelector.Parameters.Builder()
.setTunnelingEnabled(true)
.build();
player.setTrackSelectionParameters(parameters);

Expected result

The player can play stream smooth with tunneling playback mode.

Actual result

Intermittent crash at startup with unexpected runtime error.

2026-03-03 23:00:37.725 11175-11394 ExoPlayerImplInternal androidx.media3.demo.main E Playback error
androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:925)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: java.lang.IllegalStateException
at com.google.common.base.Preconditions.checkState(Preconditions.java:497)
at androidx.media3.exoplayer.video.MediaCodecVideoRenderer.onEnabled(MediaCodecVideoRenderer.java:873)
at androidx.media3.exoplayer.BaseRenderer.enable(BaseRenderer.java:151)
at androidx.media3.exoplayer.RendererHolder.enable(RendererHolder.java:500)
at androidx.media3.exoplayer.ExoPlayerImplInternal.enableRenderer(ExoPlayerImplInternal.java:3354)
at androidx.media3.exoplayer.ExoPlayerImplInternal.enableRenderers(ExoPlayerImplInternal.java:3322)
at androidx.media3.exoplayer.ExoPlayerImplInternal.enableRenderers(ExoPlayerImplInternal.java:3303)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleLoadingPeriodPrepared(ExoPlayerImplInternal.java:3106)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handlePeriodPrepared(ExoPlayerImplInternal.java:3074)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:751)

Media

demo app stream "HD(MP4, H264)"

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[zgzong]

From Commit 385498c
Initial audio session id is no longer immediately available after creating the player. When the audio session ID is available, ExoPlayerImpl will generate a message and queued in main thread, which MediaCodecVideoRenderer may not receive and update its tunnelingAudioSessionId before ExoPlayer enable renderers, which caused checkState(!tunneling || tunnelingAudioSessionId != C.AUDIO_SESSION_ID_UNSET) failure.

[craziecustomcartoons52-ctrl]

https://github.com/androidx/media/issues?q=state%3Aopen%20label%3A%22needs%20triage%22

[craziecustomcartoons52-ctrl]

#3099

[craziecustomcartoons52-ctrl]

#3099 (comment)

[craziecustomcartoons52-ctrl]

#3099

[microkatz]

@zingergarfield @craziecustomcartoons52-ctrl @zgzong

Thank you for reporting this issue! Yes, there appears to be a race condition in Tunneling mode with Audio Session ID configuration and when the Renderer is enabled.

Some background & analysis for note-keeping purposes.

Although the Audio Session ID generation will occur on the Playback thread before the task of prepare(), there are a few msg hops back to the Application thread -> Playback Thread etc. before the ID is provided to the MediaCodecVideoRenderer. This process is described below:

1. Playback Thread: Generates the audio session ID.
2. Playback Thread → Application Thread: Sends a notification that the state has changed.
3. Application Thread: Receives the notification and calls onAudioSessionIdChanged.
4. Application Thread → Playback Thread: onAudioSessionIdChanged sends MSG_SET_AUDIO_SESSION_ID to the renderers

So if the "Application Thread → Playback Thread prepare()" call resulting in MSG_PERIOD_PREPARED is addressed before that MSG_SET_AUDIO_SESSION_ID, we will run into the issue you are facing.

We are working on implementing a solution to address this. This ticket will be updated when a fix is pushed. Thanks!

[microkatz]

@zingergarfield @craziecustomcartoons52-ctrl @zgzong

A fix for this issue has been submitted to the main branch, fb5e4c8. This solution removes the race condition by ensuring that if an audio session id has been successfully generated then it will be provided to the renderers prior to the checkState. Hopefully this resolves the issue!

I will close this ticket. Feel free to re-open or create a new ticket if you have additional issues/questions.