6

I have an audio app that plays multiple tracks at the same time, each with their own mediaPlayer. Each track is reasonably long, upwards of two minutes.

So long as the tracks are encoded as ogg files, everything works great on Android 4.x. I've yet to encounter a device running stock 4.x that has any audio problems with this setup.

But on Lollipop 5.x there are a wide variety of audio problems - stuttering, tracks cutting out, and bluetooth audio almost never seems to work.

I've discovered that going into Developer options in 5.x and unchecking "use Nuplayer (experimental)" instantly solves these problems and returns to 4.x levels of performance.

Is there a way I can programmatically force my app to use the 4.x media stack (I believe it's called Awesomeplayer?) and not to use the new Nuplayer system? At least until I can discover the source of the Nuplayer problems?

verysuperfresh
  • 747
  • 1
  • 6
  • 10

2 Answers2

3

Update: Setting a partial wake lock on the MediaPlayer resolves this problem:

playerToPrepare.setWakeMode(context, PowerManager.PARTIAL_WAKE_LOCK);

A partial wake lock shouldn't have too big of an impact, and it seems like MediaPlayer itself cleans this up when playback completes.

-- Original Answer ---

So, I finally found a way to safely detect wether or not NuPlayer will be used or not on Lollipop. Seems like the best strategy for now is to inform the user to open Developer Settings and enable AwesomePlayer until Google fixes NuPlayer. Sadly, there's no good way to change this setting for the user, we can just read its value unless you're signed as a system application.

This approach checks Android's system properties values to see if the user have enabled the use of AwesomePlayer or not under Developer Settings. Since Lollipop have NuPlayer on by default, if this value is disabled, we know NuPlayer will be used.

Drop SystemProperties.java into your project for access to read the system properties, do not change its package name from android.os (it calls through to its corresponding JNI methods, so needs to stay the same).

You can now check if the phone is Lollipop/5.0, if AwesomePlayer is enabled, and act accordingly if it's not (e.g. by opening the Developer Settings):

public void openDeveloperSettingsIfAwesomePlayerNotActivated(final Context context) {
    final boolean useAwesome = SystemProperties.getBoolean("persist.sys.media.use-awesome", false);
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP && !useAwesome) {
        final Intent intent = new Intent(Settings.ACTION_APPLICATION_DEVELOPMENT_SETTINGS);
        context.startActivity(intent);                
    }
}
Sveinung Kval Bakken
  • 3,715
  • 1
  • 24
  • 30
1

Enabling/Disabling NuPlayer didn't help. But I managed the wakelock part with a friendly UI. I'll look tonight as SysCtl from KitKat and compare it with the one on Lollipop, maybe I'll find something interesting.

So bluetooth stuttering is related to the dumb kernel on 5.02 that stutters the playback as soon as screen is off. I used a partial wakelock so the cpu stays active after screen off with this app. It works. No more stuttering. As for speakers that require high sample rate I just switched the cpu governor to performance. It's a workaround but the partial wakelock should work especially on bluetooth headphones. Here's the app's link https://play.google.com/store/apps/details?id=eu.thedarken.wl&hl=en

Sebi673
  • 11
  • 1