Ensure logs from AudioTrack.getMinBufferSize are reported back to the application

[REQUIRED] Use case description

I’m getting the following crash from an user but the underlying error is not logged except on the device logcat and users are often not willing to send full bugs report dumps from their device due to the sensitive nature of those.

Unexpected runtime error
      at com.google.android.exoplayer2.ExoPlaybackException.createForUnexpected(ExoPlaybackException.java:207)
      at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:587)
      at android.os.Handler.dispatchMessage(Handler.java)
      at android.os.Looper.loop(Looper.java)
      at android.os.HandlerThread.run(HandlerThread.java)
  Caused by: java.lang.IllegalStateException
      at com.google.android.exoplayer2.util.Assertions.checkState(Assertions.java:84)
      at com.google.android.exoplayer2.audio.DefaultAudioSink$Configuration.getPcmDefaultBufferSize(DefaultAudioSink.java:2126)
      at com.google.android.exoplayer2.audio.DefaultAudioSink$Configuration.computeBufferSize(DefaultAudioSink.java:2104)
      at com.google.android.exoplayer2.audio.DefaultAudioSink$Configuration.<init>(DefaultAudioSink.java:1974)
      at com.google.android.exoplayer2.audio.DefaultAudioSink.configure(DefaultAudioSink.java:602)
      at com.google.android.exoplayer2.audio.DecoderAudioRenderer.drainOutputBuffer(DecoderAudioRenderer.java:404)
      at com.google.android.exoplayer2.audio.DecoderAudioRenderer.render(DecoderAudioRenderer.java:303)
      at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:945)
      at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:478)
      ... 3 more

Proposed solution

Have that function logs send up to the normal log Exoplayer EventLogger

Alternatives considered

• Throw directly in that function?
• Return the result as a Pair containing the error string, or using one of the common Result monad stuff then add the message to the assert.

[ojw28]

Thanks. I’ve filed [internal ref: b/192226595] to request better error codes from the platform in this case.

We might be able to determine the cause at the ExoPlayer level by mimicking the logic in the platform, but that seems very error-prone (e.g., it can easily go out of sync, and may be out of sync already on some devices if OEMs have made platform modifications). So I’m not convinced it’s a good idea.

I’ll leave this issue closed, since there’s nothing actionable here for us for the time being. If we get better error codes from the platform, then we’ll make sure to plumb those through in the future!

[Tolriq]

@ojw28

It’s all about: https://cs.android.com/android/platform/superproject/+/master:frameworks/base/media/java/android/media/AudioTrack.java;l=2300?q=getMinBufferSize&ss=android%2Fplatform%2Fsuperproject

But maybe there’s a way to detect before or better before manually from ExoPlayer?

When playing from certain server I can request transcoding on the first 3 errors to supported media, but knowing the exact cause helps a lot to better determine what to transcode to. And as if it did not transcode first it means either the device was supposed to support the media or I failed some prechecks earlier so maybe I have something to fix but can’t really know easily.

BTW I’m using ffmepg for audio so don’t really know what kind of data reaches here and maybe there’s something I’m supposed to do so that ffmepg does something to not trigger such errors.