-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AudioTrack write failed: -6 #627
Comments
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. |
I confirmed that it failed to play, and more detailed logs I have sent to [email protected], the title is: Replenish:
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) My application has enabled audio offload by default. It seems that it is the culprit. Other information: |
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. |
That's an important piece of information :) And yes, it definitely seems to be related to using offload.
That makes sense too now, because screen recording completely disables the offload path on the device to be able to capture audio output.
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. |
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:
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. |
If offload fails at first write with [ERROR_DEAD_OBJECT](https://developer.android.com/reference/android/media/AudioTrack#ERROR_DEAD_OBJECT), then try disabling offload mode and try again. This allows recovery in a state where AudioTrack succeeds init in offload mode but writing is failing. Issue: #627 PiperOrigin-RevId: 564402181
If offload fails at first write with [ERROR_DEAD_OBJECT](https://developer.android.com/reference/android/media/AudioTrack#ERROR_DEAD_OBJECT), then try disabling offload mode and try again. This allows recovery in a state where AudioTrack succeeds init in offload mode but writing is failing. Issue: androidx/media#627 PiperOrigin-RevId: 564402181
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. |
If offload fails at first write with [ERROR_DEAD_OBJECT](https://developer.android.com/reference/android/media/AudioTrack#ERROR_DEAD_OBJECT), then try disabling offload mode and try again. This allows recovery in a state where AudioTrack succeeds init in offload mode but writing is failing. Issue: androidx#627 PiperOrigin-RevId: 564402181
If offload fails at first write with [ERROR_DEAD_OBJECT](https://developer.android.com/reference/android/media/AudioTrack#ERROR_DEAD_OBJECT), then try disabling offload mode and try again. This allows recovery in a state where AudioTrack succeeds init in offload mode but writing is failing. Issue: androidx#627 PiperOrigin-RevId: 564402181
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
Media
Not applicable
Bug Report
adb bugreport
to [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: