Skip to content

AudioTrack write failed: -6 #627

Closed
Closed

Description

@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

Activity

  1. changed the title [-]OnePlus [/-] [+]AudioTrack write failed: -6[/+] on Sep 1, 2023
  2. tonihei commented on Sep 6, 2023

    @tonihei
    Collaborator

    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.

  3. lyswhut commented on Sep 6, 2023

    @lyswhut
    Author

    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

  4. Tolriq commented on Sep 6, 2023

    @Tolriq
    Contributor

    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.

  5. tonihei commented on Sep 7, 2023

    @tonihei
    Collaborator

    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.

  6. assigned and unassigned on Sep 7, 2023
  7. lyswhut commented on Sep 8, 2023

    @lyswhut
    Author

    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

    image

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

    Unfortunately, I cannot collect these devices and types :(

  8. microkatz commented on Sep 8, 2023

    @microkatz
    Contributor

    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.

  9. microkatz commented on Sep 13, 2023

    @microkatz
    Contributor

    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.

  10. locked and limited conversation to collaborators on Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions