-
Notifications
You must be signed in to change notification settings - Fork 6k
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 init failed when Bluetooth is connected #9712
Comments
How confident are you that this problem didn't occur with 2.11.8? If this is indeed the case then something in the
Just to clarify: This bug happens when the headset is already connected when the playback starts. So it's not related to plugging in the headset during playback? Also, did your error reports contain anything special about the type or capabilities of the headsets involved?
Generally, the initialization of an |
I can't say this problem never occurred with 2.11.8. I may receive one similar bug report in a week with 2.11.8. With 2.12.0, I receive around 10 related bug reports every day. I tried reverting to 2.11.8 and those affected users told me this problem went away. Obviously this bug happens a lot more frequently since 2.12.0. I've tried disabling
Based on the information I gathered this bug happens when the headset is already connected before the playback starts. I haven't asked my users to test whether this bug still happens when plugging in the headset during playback.
I saw different headsets were used. I don't think it's related to a specific headset model.
Yes, this is what puzzles me most. One user even sent me a video showed he couldn't start playing with headset connected. He disconnected the headset, then it played just fine. Below is one
|
The audio format is stereo pcm, its suprizing it would fail. Has any of your user shared a bug report with you? It contains the system logcat at the time of the error would gave us much more information about the issue as well as the dumpsys of media.audio_policy would give us the BT capabilities. If no bug report is available, the logcat around the time of the playback failure would be helpfull. |
The fact that it is related to Bluetooth is not overly suprizing. Bluetooth has a very complex state where a lot can go wrong. It could be for example that the Bluetooth stack errors attempting to start start playback in a particular state. We will know more when we can have the framework error logs when init fails. |
Sent the bug report to [email protected]. Thanks. |
Turns out the error is caused by Here is the bug report generated after this bug happened and Bluetooth headset still connected. Here is the screenshot of the demo app with the playback failed message. |
Thanks for the bug report. The error is logged just before the init failure: The issue is that when This might be due to Binders max memory allocation of 1MB (documented https://developer.android.com/reference/android/os/TransactionTooLargeException), or it might due to memory exaustion on low memory device. Especially if this is only reproduced on low memory devices. Testing is required to make sure there is a hard limit of 1MB to AudioTrack buffers. If there is, we should cap the AudioTrack buffer size to 1MB to avoid this issue. Otherwise, we would have to implement a retry with a smaller buffer size. |
The plan is currently to limit the buffer to 1MB with a minimum of the minimum buffer size as reported by AudioTrack. In pseudocode: |
This mean that outragously high bandwith playback like 32bit 96kHz 7.1 surround (3MB/s) would probably start having underrun at arround 2x (162ms for 1MB buffer). In those cases it would be preferable to have a bigger buffer. |
Looking forward to the fix. Thanks! |
Some phone with limited memory can't allocate bigger shared memory buffers. This might or might not be related to Binder's 1M transaction limit. Tested on Pixel 4 by setting the minimum buffer size to 1h. google/ExoPlayer#9712 #minor-release PiperOrigin-RevId: 425324536
Some phone with limited memory can't allocate bigger shared memory buffers. This might or might not be related to Binder's 1M transaction limit. Tested on Pixel 4 by setting the minimum buffer size to 1h. #9712 #minor-release PiperOrigin-RevId: 425324536
Just curious - was it ever confirmed that these pushes fixed the issue? Plex claims to implement 2.17.1, but what appears to be the same issue is still occurring: `04-21 07:34:53.561 i: [FFmpeg] [INFO] [hls @ 0xb42f1400] Opening 'https://192-168-1-34.91039e1f9ebe40ed851bfb93ab971b53.plex.direct:32400/video/:/transcode/universal/session/27cf9f1a4f9197d3-com-plexapp-android/base/00159.ts' for reading 04-21 07:34:53.600 i: [MediaCodecVideoSyncRenderer] Decoder initialised, after 0 attempts. 04-21 07:34:55.726 i: [FFmpeg] [INFO] [https @ 0xadc1f800] Opening 'https://192-168-1-34.91039e1f9ebe40ed851bfb93ab971b53.plex.direct:32400/video/:/transcode/universal/session/27cf9f1a4f9197d3-com-plexapp-android/base/00161.ts' for reading 04-21 07:34:55.955 i: [ExoPlayer][EventLogger] videoDisabled [eventTime=4.33, mediaPos=1599.51, window=0, period=0] 04-21 07:34:56.025 i: [Player][Timeline] Player error not known by server, reporting original player error (or a playback interrupted one) |
The original bug reported in this issue tracking has been fixed. Thanks! |
This bug was first observed after updating from ExoPlayer
2.11.8
to2.12.0
and still happens with latest ExoPlayer2.16.0
.I haven't been able to reproduce the bug myself yet but I've received many bug reports from my users. The bug happens when Bluetooth headset is connected, start playing will fail with
AudioTrack init failed
. Disconnecting the Bluetooth headset, then it will start play without any issue.My player code is:
This bug mostly happens on low end devices but it can also happen on high end devices such as Pixel 3.
Any help is appreciated.
The text was updated successfully, but these errors were encountered: