MediaPlayer small audio drop outs playing MP3/AAC http streams on Google Pixel devices [394350446]

Assigned

Bug

[AOSP] assigned

Status Update

No update yet.

Description

pu...@gmail.com

created issue #1

Feb 5, 2025 09:52AM

I'm the developer of an app that plays MP3/AAC http streams. It uses MediaPlayer, playing a http URL pointing to a MP3/AAC stream. Nothing special here.

Since a while, only on Google Pixel devices (starting at least at Pixel 6 up to Pixel 9, with various Android versions up to the latest stable Android 15), there is a buffering issue resulting in periodic small audio drop out, every time MediaPlayer does buffering.

Each time there is a drop out, logcat shows:

MediaPlayerNative  W   58:41.459  info/warning (703, 0)
                         W   58:41.460  info/warning (701, 0)
                         W   58:41.483  info/warning (703, 0)
                         W   58:41.483  info/warning (702, 0)

code 701 is MEDIA_INFO_BUFFERING_START whose documentation in mediaplayer.h says:

// MediaPlayer is temporarily pausing playback internally in order to
// buffer more data.
MEDIA_INFO_BUFFERING_START = 701,

So audio is briefly pausing until code 702 (MEDIA_INFO_BUFFERING_END) is received 23ms, enough for the drop out to be heard.

It would be really great to see this buffering issue fixed because it only happens on Google Pixel devices (to my knowledge). In my app I have a workaround that replaces MediaPlayer by FFmpeg for the decoding, but not all apps will have that luxury.

To reproduce it on a Google Pixel:

initialize a MediaPlayer instance to play a MP3 or AAC http stream (MediaPlayer#setDataSource)
as music is playing, observe small audio drop outs every 20-30s as MediaPlayer is buffering, with related traces in logcat

Comments

fr...@gmx.de <fr...@gmx.de> #2Feb 5, 2025 11:52AM

Running into a similar issue, any update on this?

vi...@google.com <vi...@google.com> #3Feb 5, 2025 02:38PM

Assigned to vi...@google.com.

This is a platform behavior change.

b/236862874 is related.

pu...@gmail.com <pu...@gmail.com> #4Feb 5, 2025 03:06PM

Reassigning to current owner per go/androidx/owners.

pu...@gmail.com <pu...@gmail.com> #5Feb 5, 2025 03:07PM

Re-triaging by request.

vi...@google.com <vi...@google.com> #6Feb 7, 2025 02:02AM

Any progress?

pu...@gmail.com <pu...@gmail.com> #7Feb 10, 2025 03:33PM

deleted

pu...@gmail.com <pu...@gmail.com> #8Feb 11, 2025 10:32AM

Thanks for the comment#1 report. The bug in how those older versions of the framework dispatch insets does make handling insets difficult. It's on our roadmap for early 2025 to prepare an AndroidX-side workaround.

vi...@google.com <vi...@google.com> #9Feb 13, 2025 04:47AM

Any possible workaround for us before that ? We're currently migrating our app to be edge-to-edge as per Android 15 migration and this would force us to make API 30-specific cases everywhere

ib...@google.com <ib...@google.com> #10Feb 14, 2025 05:28PM

This issue is also stopping us from being able to support edge-to-edge in Android 15. Given it's a enforced requirement for targeting Android 15, couldn't this be prioritised higher? Companies like us have hundreds of screens to fix so waiting until 2025 for a workaround is going to be tough work.

pu...@gmail.com <pu...@gmail.com> #11Feb 14, 2025 05:55PM

Maybe you can create a static method, com.your.company.ViewGroupCompat#installCompatInsetsDispatch, like this: https://android-review.googlesource.com/c/platform/frameworks/support/+/3310617/2/core/core/src/main/java/androidx/core/view/ViewGroupCompat.java ?

After creating the method, you need to call ViewGroupCompat.installCompatInsetsDispatch(getWindow().getDecorView()) in onCreate() of your activity to make the behavior compatible with API 30+.

When the new library with the API is released, you can replace com.your.company.ViewGroupCompat with androidx.core.view.ViewGroupCompat.

pu...@gmail.com <pu...@gmail.com> #12Mar 9, 2025 09:05AM

Wow quick response, thanks! I just tried applying that workaround to our root view and can confirm it fixes the issue. (Also FYI there's a typo in the PR; "comsumed")