The stack trace you showed looks like some internal audio routing changed, the AudioTrack fails with ERROR_DEAD_OBJECT (-6), presumably because the existing AudioTrack is no longer supported and needed to be recreated by the system, and then the player automatically retries playback. From the stack trace you've shown it doesn't even look as if playback failed at all? Can you confirm that playback actually failed, or did you just log this stack trace?

If you are able to reproduce this yourself on one of the mentioned devices, could you check if it happens with the demo app too and provide the failing stream if needed? (and any other relevant reproduction steps)

The main audio related changes in 2.18.0 are around audio spatialization. Do these streams have multi-channel content that could be affected by this somehow?

@tianyif Assigning to you for now since this falls into your area of expertise.

From the stack trace you've shown it doesn't even look as if playback failed at all? Can you confirm that playback actually failed, or did you just log this stack trace?

I confirmed that it failed to play, and more detailed logs I have sent to [email protected], the title is: Issue #627

Replenish:

Working in 2.17.1 and before

Even if the downgrade reaches 2.17.1, I still receive some user feedback this error, which is only effective for some users.

This error that will only appear on some devices, it seems to have nothing to do with audio files (at least all audio is like this)
Some users cannot play audio at all, and some users cannot play audio completely.

My application has enabled audio offload by default. It seems that it is the culprit.
I added a switch that allows users to turn off the audio offload. For users who encounter this error, they only need to turn off the audio offload to restore work.

Other information:
Apk File: releases
Player module source code: react-native-track-player fork

I did subscribe on this one as facing the same issue with offload on some devices. (Still the case with 1.2.0 alpha 1)

I had no time to investigate but it started to occur relatively recently and I can reproduce on my Pixel 6 Pro with different Exoplayer version. I wonder if this is not a recent AOSP change.

My application has enabled audio offload by default.

That's an important piece of information :) And yes, it definitely seems to be related to using offload.

if you run the "screen record" app, the player will work normally

That makes sense too now, because screen recording completely disables the offload path on the device to be able to capture audio output.

This error that will only appear on some devices, it seems to have nothing to do with audio files (at least all audio is like this)

If you can reproduce this, could you check that same problem happens if you play the file in the ExoPlayer demo app?

And can you also share the combination of devices and type of media where this happens? If it's consistent, it might just be a buggy implementation of the offload decoding implementation on these devices and maybe we can/should mark these as unsupported.

Lastly, I think we have (or used to have) code that automatically retries with non-offload after offload failed to play.
@microkatz Is this true? If so, I wonder why this didn't work here.

If you can reproduce this, could you check that same problem happens if you play the file in the ExoPlayer demo app?

I confirm that the Exoplayer Demo app can reproduce the problem. The new log has been sent to [email protected]

To reproduce this problem, just add this on demo:

https://github.com/google/ExoPlayer/blob/03cadd2c809596e8922129f03ff2212618414734/demos/main/src/main/java/com/google/android/exoplayer2/demo/DemoUtil.java#L82-L93

And can you also share the combination of devices and type of media where this happens?

Unfortunately, I cannot collect these devices and types :(

Hello @lyswhut,

The issue stems from that the device says it supports offload for the format, the device allows creation of an AudioTrack in offload mode, but then oddly fails when trying to write to the AudioTrack. Because ExoPlayer successfully builds the AudioTrack with offload, ExoPlayer does not retry in your scenario by disabling offload.

I am currently working on a fix to allow retry with disabling offload for that write error case. This fix will hopefully address your your playback issue as ExoPlayer will fallback to a decoding path.

However, still seems that there is a device-specific issue. The device is incorrectly reporting offload support.

I'll update this thread when the code has been pushed.

Hello @lyswhut,

A commit has been pushed to the main branch of the androidx/media repo. Here is the link, 3742f6b. Hopefully that should at least address your issue of not being able to stream at all. The commit allows automatic falling back to the decoder path if ExoPlayer is failing to write bytes downlevel in offload mode.