Okay, from a little more experimentation it appears after loading/
unloading 256 sounds things start to go awry. It seems to be 100%
reproducible in my application. I wasn't actually running the latest
Android SDK so I updated to latest, and specified the minimum/target
SDK version to be eight (instead of four) just for good measure, but
this doesn't help. After 256 sounds have been unloaded, the next load
never appears to complete.

After more searching on Google (I think I have read every result it
returns now), I came across this web page (in Japanese):

http://d.hatena.ne.jp/itog/20100927/1285550195

The Google translation does a good enough job for me to get the point
being conveyed (I believe). It says:

[Begin quote]
256 Wall
--------

load () will be returned in the id is incremented from 0, for
convenience of memory management in the region of 256 native id
number. Me a total 257 load () error when trying to become.

ERROR / SoundPool (2693): Unable to load sample: (null)

unload () even if the load () can retrieve the id is not reused. To
clear the id

soundPool.release ()
The only state to clean everything once.
[End quote]

My interpretation of that is that there is an integer index, ever time
you load a sound you get back an incremented index. On the 257th load,
the index value you get back is 257, that this causes it to fail to
load with the above message (I actually get the above message with the
latest SDK and target version set to eight). When you get to this
stage, the only option appears to be to release the entire SoundPool,
create a new one, and carry on.

This seems to completely match what I am experiencing, so if this is
the case I am at least happy that my code is correct, but I am sad
that this is as good as it gets. It is not convenient for me to have
to destroy the SoundPool once an arbitrary number of sounds have been
loaded and unloaded. On the positive side, I can make some special
case code in my current application to have a sensible time to dump
out all sounds, clear the sound pool and recreate it, but it is far
from neat, and certainly not going to be a project generic, or
platform generic solution (I have never seen a platform like this
before where there is such a limit - certainly none of my other cross
compile targets suffer from this issue).

I would be interested to hear of anyone that believes that can
actually beat this 256 limit without calling 'release' on their
SoundPool. I do not feel my application is being particularly
demanding in terms of the SFX requirements. It is a platform based
game, and each level loads in a bunch of SFX specific for that level,
each level is relatively quick (some can just be a few seconds) so if
you play for a moderate amount of time, it is rather easy to have
loaded more than 256 sounds loaded and unloaded.

darrinps: It would be interesting to know if you have overcome this
hurdle, or if you simply haven't hit the 256 limit.

Steve

On Jan 25, 11:47 pm, Steve <rockthesm...@gmail.com> wrote:
> Unfortunately I am rather confident that all my play's have matching
> stops, and my loads have matching unloads.
>
> I have managed to create my bug quite quickly at least, if I just
> quickly jump between a couple of levels continually until it has
> loaded/unloaded 500 or so samples that seems to break it. After that
> point no more new sounds appear to want to load - no errors - they
> just never load.
>
> Things I have tried to night to remedy this include:
>
> 1. Do not allow a sound to be unloaded sooner than five seconds after
> it was loaded (if it is requested to be unloaded sooner than five
> seconds it simply gets put on a queue and processed when five seconds
> is up.
>
> 2. Do not allow more than one unload (at all, across all SFX) to
> unload within a five second internal.
>
> I pulled the five second value out of the air, but it seemed like a
> reasonable time for my very short samples to be loaded/unloaded -
> anyway, the net result is the bug is still present. I can't think of
> what to try next, except to try and narrow down if there is a
> particular number of loads/unloads that causes this bug, and
> potentially trying to put together a cut down sample that displays it.
> The way it looks right now, the cut down sample could be extremely
> simple, as in:
>
> loop 500 times:
>   id = load( xyz );
>   unload( id )
>
> id = load( xyz );
> sleep( 10_seconds );
> play( xyz );
>
> It feels like the play call right at the bottom should exhibit the
> problem, as I say, I might have to see if I can repro this in a simple
> sample...
>
> Steve
>
> On Jan 25, 3:28 pm, darrinps <darri...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I have a sound based application on the market and use SoundPool.
>
> > Long story short, it is quirky to say the least and only likes small
> > sound files. I have been able to play sounds over and over (as in a
> > loop) and change sounds though without issue once I matched up loading
> > and unloading correctly.
>
> > I don't have the code on me right now but can get it to you later. For
> > now though, keep the files small, and unloading matched, and it should
> > work.
>
> > On Jan 24, 7:45 pm, Steve <rockthesm...@gmail.com> wrote:
>
> > > Hi there,
>
> > > I am using a SoundPool to control the SFX in my game, which is
> > > targeted at Android 1.6 devices. Initially, I am able to do everything
> > > I wish to do, but after sometime of playing the game (can be a few
> > > minutes, can be more than thirty minutes), I am no longer able to play
> > > sounds, and instead am seeing messages in my log such as:
>
> > > SoundPool - sample 440 not READY
>
> > > The thing is, these samples never become ready - in fact from this
> > > moment on, no sound effects ever appear to be ready - it is almost as
> > > if the thread that handles the loading gets stuck and then no more
> > > sounds can load.
>
> > > Any sounds that are loaded for the duration of the game can still be
> > > played and function correctly, but sounds that get loaded per level
> > > will no longer work from this point on.
>
> > > I have a session of my game running now that is exhibiting this
> > > problem, and some statistics I have are:
>
> > >  - I have made 516 calls to load
> > >  - I have made 513 calls to unload (I have three sounds that are
> > > resident, all the other loads/unloads are as I have gone in and out of
> > > many levels)
> > >  - I have made 1547 play calls
> > >  - I have made 1547 stop calls
>
> > > I have spent some time debugging this now, and have ensured all load
> > > and unloads match up, and the same for play/stop calls, but I am not
> > > really sure what I can do next now. My only fallback I could code up
> > > is to destroy the sound pool from time to time, and reload the
> > > resident sounds - it isn't a clean solution, but I am at a loss as to
> > > what else I can do. It feels like the problem is more likely to crop
> > > up when loading/unloading lots of SFX in succession, I am not sure if
> > > it could be a race case to do with a resource not quite being in a
> > > loaded state, and not quite being in an unloaded state - of course
> > > this whole situation is made a lot worse by the fact I don't have a
> > > sensible method of querying when a sound is actually loaded in Android
> > > 1.6.
>
> > > Someone out there must have a largish game on Android 1.6, using the
> > > SoundPool successfully? Can anyone help?
>
> > > Many thanks,
>
> > > Steve

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to