MediaPlayer -- maximum count and its influencing factors

[Tamás Kovács]

Hello,

In my game app, I use SoundPool for quick short sounds, but I also
employ a few instances of MediaPlayer for certain reasons (more rich
control, getCurrentPosition/seekTo, etc.).

More precisely, 1 MediaPlayer is playing a longer sound (~3 MB), and
3-4 other MediaPlayers are used for small sounds (40-80 KB). The
longer sound is played all the time, the small sounds are occassional
(but I keep all MediaPlayers in prepared state).

I read somewhere that the system doesn't expect me to use more than 2
MediaPlayers at the same time. Is this because of their bigger
footprint and complexity (and thus bigger memory usage), or is there
some other (formal) restriction too?

(If it's only an empirical limit related to memory usage, then I
suppose it's fine to use many -- e.g. five -- MediaPlayers *provided*
the loaded sounds are small.)

[Glenn Kasten]

For audio, there's a hard limit of 32 active 

AudioTrack objects per _device_ (not per app:

you need to share those 32 with rest of the system), 

and AudioTrack is used internally beneath SoundPool, ToneGenerator,

MediaPlayer, native audio based on OpenSL ES, etc.

But the actual AudioTrack limit is < 32; it depends more on

soft factors such as memory, CPU load, etc.

Also note that the limiter in the Android audio mixer does not currently

have dynamic range compression, so it is possible to clip

if you have a large number of active sounds and they're all loud.

For video players the limit is much much lower due to the intense

load that video puts on the device. 

I'll use this as an opportunity to remind media developers: please

remember to call release() for media objects when your app is paused.

This frees up the underlying resources that other apps will need.

Don't rely on the media objects being cleaned up in finalize

by the garbage collector, as that has unpredictable timing.

[Tamás Kovács]

OK, so practically, 1 MediaPlayer I use corresponds to 1 AudioTrack
from the system.

Important question: released MediaPlayers (i.e. those which got
release() from me) do not count, right? I.e. if I have 7 Media Players
but 5 from those were already released, I use up only 7-5=2
AudioTracks from the global system pool. Is this correct?

(Therefore, if all applications correctly cared for releasing in their
onStop/onPause, then it is difficult to reach the hard limit you
mentioned; because only the foreground and possibly some paused apps
use up AudioTracks -- except for the OS, of course).

[Glenn Kasten]

Correct

On Saturday, April 28, 2012 3:40:25 AM UTC-7, Tamás Kovács wrote:

[Glenn Kasten]

1. release() should let go of the underlying resource immediately (FYI the technical term is an IAudioTrack)

2. Not that I know of. Can you please post a snippet of code that demonstrates the problem? Include the part that creates and configures the AudioTrack, as well as the part that releases it.  Probably don't need the part that writes to the AudioTrack, but if you can include that it might be helpful.  Another thing that would be helpful is to include the output of "adb shell dumpsys media.audio_flinger" at each of these times: before creating the tracks, after creating the tracks, and then after you call release() on the tracks but before you create any other tracks.  The output will include a column called "pid" for process ID.  Use "adb shell ps | grep ###" to see which process name corresponds to which process ID. That will help us to figure out what's going on with the IAudioTrack resources.

On Friday, August 10, 2012 9:10:37 PM UTC-7, brooker wrote:

1) On this topic, just to confirm-  if one were to call release() on an AudioTrack, would it be instantly released, such that you could then instantiate a new AudioTrack and not increase the number of used tracks-  or would it only be released when the garbage collector runs?

2) I've got a situation where we have about 12 audiotracks.  Sometimes we stop/release and create a new one attempting to keep the number used constant.  But we're finding on the Nexus 7 w/Jelly Bean, it's hitting a limit and errors out, as if the tracks aren't being released.  Did something change in Jelly Bean, or on the Nexus 7?

Thanks!

[Glenn Kasten]

On device you omit the "adb shell" prefix; that's needed for the host command line only.

I'm not an expert in this area, but I think to exec on device you'll need to read the output stream yourself

and then log it; see paragraph 2 of http://developer.android.com/intl/fr/reference/java/lang/Process.html

In general using the shell within an app is not recommended, and there might be security limitations.

How about just putting a long delay in your app at appropriate times, along with a Toast indicating the progress point,

to give you time to execute adb shell on your host? Then you don't have to worry about exec on device.

On Wednesday, August 15, 2012 3:21:41 PM UTC-7, brooker wrote:

Glenn,

Thanks a lot for the response.  

Note, I wrote a few more details in a later post because this one wasn't released by the moderator for four days. here's the other post:

https://groups.google.com/d/msg/android-platform/oxzdCJcN6MM/E6PRfH3TMbIJ

I haven't actually run adb from code before- should I be doing this through: Process process = Runtime.getRuntime().exec("adb shell dumpsys media.audio_flinger")?

[brooker]

Glenn,

Still working on this issue.  I did try dumping audio_flinger and noticed that when I get the track creation failure the system is already using 8 tracks in addition to my 22.   The 8 system tracks are as follows:

system_server

/system/bin/mediaserver

com.android.systemui

com.android.phone

and,

com.google.android.googlequicksearchbox (x4)

If I dump audio_flinger after exiting my app, I only see the following 4 tracks:

system_server

/system/bin/mediaserver

com.android.systemui

com.android.phone

When I dump audio_flinger on Nexus One running 2.3.4 I see 1 track belonging to com.android.phone, and 22 belonging to my app.

Could com.google.android.googlequicksearchbox (or the others, not including com.android.phone) be the reason I'm getting failures on Nexus 7/Jelly Bean and not other devices platforms?

Thanks

[trizey]

Are there any updates to this or did anyone figure this out? We're running into the same issue, specifically on a Nexus 7 running 4.2.2. We have a maximum of 5 tracks at once and we release them when they're not needed. After a period of time, we eventually start getting creation failures with no more track names available. We are able to create tracks again after killing the process and restarting the app.