AudioTrack write failed: -6

[lyswhut]

Version

ExoPlayer 2.18.2-2.19.1

More version details

2.18.0 Unknown

Working in 2.17.1 and before

Devices that reproduce the issue

OnePlus ColorOS 13.1, Android 13

Devices that do not reproduce the issue

Xiaomi 12, Android 13

Reproducible in the demo app?

No

Reproduction steps

This error will receive any online MP3 file, but if you run the "screen record" app, the player will work normally

Expected result

The media plays successfully

Actual result

09-01 10:27:47.948  4743  6553 D Avrcp_ext: isMusicActive = false mAudioPlaybackIsActive = true player state = PlaybackState {state=0, position=0, buffered position=0, speed=1.0, updated=978806, actions=311, custom actions=[], active item id=-1, error=null}
09-01 10:27:47.949  4743  4743 D OplusBluetoothAudioGuard: AudioManager Player in started state: cn.toside.music.mobile
09-01 10:27:47.949  4743  4743 D OplusBluetoothAudioGuard: AudioManager Active Player: cn.toside.music.mobile
09-01 10:27:47.949  4743  4743 D OplusBluetoothAudioGuard: send MESSAGE_MEDIA_STATE_CHANGE_CHECK
09-01 10:27:47.949  8829 10308 D MIDASApplication: MIDASHandler: switch message
09-01 10:27:47.949  9818 11079 E AudioTrack-JNI: Error -32 during AudioTrack native read
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer: Audio sink error
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:   k5.x$e: AudioTrack write failed: -6
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at k5.m0.q0(Unknown Source:175)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at k5.m0.d0(Unknown Source:24)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at k5.m0.u(Unknown Source:371)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at k5.w0.R0(Unknown Source:45)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at a6.t.Q(Unknown Source:62)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at a6.t.p(Unknown Source:47)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at i5.n1.n(Unknown Source:97)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at i5.n1.handleMessage(Unknown Source:220)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at android.os.Handler.dispatchMessage(Handler.java:102)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at android.os.Looper.loopOnce(Looper.java:240)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at android.os.Looper.loop(Looper.java:351)
09-01 10:27:47.949  9818 11079 E MediaCodecAudioRenderer:       at android.os.HandlerThread.run(HandlerThread.java:67)
09-01 10:27:47.950  4743  6774 I OplusBtAudioRouteMonitor: updateAudioPlaybackList() isMusicActive: true, virtualCallActive: false
09-01 10:27:47.950  4743  6774 D OplusBtAudioRouteMonitor: handleAudioPlaybackConfigsChanged() virtual call: false->false, music play: false->true
09-01 10:27:47.950  4743  6774 D OplusBtAudioRouteMonitor: handleAudioPlaybackConfigsChanged() a2dp record: false, a2dp state: 0, sco record: false, sco state: 0
09-01 10:27:47.950  4743  6774 D OplusBtAudioRouteMonitor: clearDiedAudioPlayerbackList()
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal: Recoverable renderer error
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:   i5.t: MediaCodecAudioRenderer error, index=1, format=Format(null, null, null, audio/mpeg, null, -1, null, [-1, -1, -1.0], [2, 44100]), format_supported=YES
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at i5.n1.handleMessage(Unknown Source:346)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at android.os.Handler.dispatchMessage(Handler.java:102)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at android.os.Looper.loopOnce(Looper.java:240)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at android.os.Looper.loop(Looper.java:351)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at android.os.HandlerThread.run(HandlerThread.java:67)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:   Caused by: k5.x$e: AudioTrack write failed: -6
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at k5.m0.q0(Unknown Source:175)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at k5.m0.d0(Unknown Source:24)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at k5.m0.u(Unknown Source:371)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at k5.w0.R0(Unknown Source:45)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at a6.t.Q(Unknown Source:62)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at a6.t.p(Unknown Source:47)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at i5.n1.n(Unknown Source:97)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       at i5.n1.handleMessage(Unknown Source:220)
09-01 10:27:47.951  9818 11079 W ExoPlayerImplInternal:       ... 4 more

Media

Not applicable

Bug Report

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

[tonihei]

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.

[lyswhut]

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 android-media-github@google.com, 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

[Tolriq]

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.

[tonihei]

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.

[lyswhut]

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 android-media-github@google.com

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 :(

[microkatz]

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.

[microkatz]

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.