AudioOffload with Widevine Content

[lemondoglol]

hi team, I was following the steps here https://developer.android.com/media/media3/exoplayer/track-selection#audioOffload to enable AudioOffload. It works fine with ADRM file, however, when I try to create the same player for Widevine, I got Player is accessed on the wrong thread. Current thread main, expected Exoplayer-application-thread (the Handler thread I created), I set the looper already.

If I remove the AudioOffload changes, then my widevine content can be played again, so don't think it is content issue.

There are not much info related to the AudioOffload online, so plz help! Thanks in advance!

Here are part of the code.

            val audioOffloadPreferences =
                TrackSelectionParameters.AudioOffloadPreferences.Builder()
                    .setAudioOffloadMode(TrackSelectionParameters.AudioOffloadPreferences.AUDIO_OFFLOAD_MODE_ENABLED)
                    // Add additional options as needed
                    .setIsGaplessSupportRequired(true)
                    .build()

            val exoPlayer: ExoPlayer = ExoPlayer.Builder(
                context,
                RenderersFactory,
                DefaultMediaSourceFactory
            )
                .setLoadControl(loadControl)
                .setLooper(applicationThread.looper)
                .setWakeMode(WAKE_MODE_NETWORK)
                .setTrackSelector(trackSelector)
                .build()

            exoPlayer.trackSelectionParameters = exoPlayer.trackSelectionParameters
                .buildUpon()
                .setAudioOffloadPreferences(audioOffloadPreferences)
                .build()

[icbaker]

Please can you provide the full stack trace that was logged with the Player is accessed on the wrong thread, so we can see where the access is coming from?

Also note that audio offload has nothing to do with whether the player runs on the main thread or a background thread, and we generally recommend always putting the player on the main thread if possible.

[lemondoglol]

there are not much info related to this, it just failed to create the player

dispachCmd:oplusGetRtt
handleGetRttCmd: netId = 121, uid = 10446
dispachCmd cmd:oplusGetRtt  result:18
Could not open '/proc/sys/kernel/sched_pelt_multiplier'
error : 2, No such file or directory
[main]Illegal state exception while building SimpleExoPlayer: Player is accessed on the wrong thread.
Current thread: 'main'
 Expected thread: 'ExoPlayer-application-thread'
See https://developer.android.com/guide/topics/media/issues/player-accessed-on-wrong-thread

  [DRMDEV] DRM_IOCTL_MTK_KICK_IDLE failed, drm_id_crtc: 64, error: -1 

[icbaker]

It looks like some code in your application (outside the media3 library) is catching the exception and logging only the message without the stack trace. Please can you change this to include the stack trace too? Without the stack trace, it's very hard to understand where the wrong-threaded access is coming from.

[lemondoglol]

here is the StackTrace

27419-27419 Lemondog                 D  stackTrace java.lang.IllegalStateException: Player is accessed on the wrong thread.
                                        Current thread: 'main'
                                        Expected thread: 'ExoPlayer-application-thread'
                                        See https://developer.android.com/guide/topics/media/issues/player-accessed-on-wrong-thread
                                            at androidx.media3.exoplayer.ExoPlayerImpl.verifyApplicationThread(ExoPlayerImpl.java:2860)
                                            at androidx.media3.exoplayer.ExoPlayerImpl.getTrackSelectionParameters(ExoPlayerImpl.java:1230)
                                            at com.xxx.playersdk.player.xxxPlayerFactory.getExoPlayerWrapper(xxxPlayerFactory.kt:227)
                                            at com.xxx.playersdk.player.xxxPlayerFactory.access$getExoPlayerWrapper(xxxPlayerFactory.kt:64)
                                            at com.xxx.playersdk.player.xxxPlayerFactory$generateNewPlayer$1.invoke(xxxPlayerFactory.kt:122)
                                            at com.xxx.playersdk.player.xxxPlayerFactory$generateNewPlayer$1.invoke(xxxPlayerFactory.kt:111)
                                            at com.xxx.playersdk.exoplayer.util.HandlerThreadHelper.runBlocking$lambda$0(HandlerThreadHelper.kt:28)
                                            at com.xxx.playersdk.exoplayer.util.HandlerThreadHelper.$r8$lambda$XmLRzlYBYJfvAD0iY8Pa1MbknFQ(Unknown Source:0)
                                            at com.xxx.playersdk.exoplayer.util.HandlerThreadHelper$$ExternalSyntheticLambda0.run(Unknown Source:6)
                                            at android.os.Handler.handleCallback(Handler.java:958)
                                            at android.os.Handler.dispatchMessage(Handler.java:99)
                                            at android.os.Looper.loopOnce(Looper.java:230)
                                            at android.os.Looper.loop(Looper.java:319)
                                            at android.app.ActivityThread.main(ActivityThread.java:8893)
                                            at java.lang.reflect.Method.invoke(Native Method)
                                            at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:608)
                                            at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1103)

[lemondoglol]

            exoPlayer.trackSelectionParameters = exoPlayer.trackSelectionParameters
                .buildUpon()
                .setAudioOffloadPreferences(audioOffloadPreferences)
                .build()

the error seems like to be here (xxxPlayerFactory.kt:227). but still not quite sure why it works fine for ADRM.

[icbaker]

The stack trace shows your app's xxxPlayerFactory is invoking ExoPlayer.getTrackSelectionParameters on the main thread whereas you've configured ExoPlayer to run on the ExoPlayer-application-thread. This looks like an issue with your app's architecture, rather than something we can help you with from the library perspective.

[lemondoglol]

thanks for the reply, mb, the issue was caused by .setLooper(applicationThread.looper)...