This doesn't solve your 256 limit problem but I just wanted to point out you can still see "sample XXX not READY" even if you're only using 2 or 3 very short sound samples. I've seen this with a <1 second OGG file on the Nexus One.
Now I'm not suggesting this is the best way to deal with it, but I play sounds from a non UI thread and use code similar to this to prevent the need to reload samples: http://code.google.com/p/cgmd2010/source/browse/trunk/src/at/ac/tuwien/cg/cgmd/bifth2010/level84/SoundManager.java?spec=svn1192&r=1192 Additionally, to deal with the larger samples (still under 1 second) not being ready I use this awful fix. int result = 0; int abortCount = 100; do { result = mSoundPool.play(mSoundPoolMap.get(resID), streamVolume, streamVolume, 1, 0, 1f); if(result == 0) { try { Thread.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); } } } while(result == 0 && abortCount-- > 0); This is not good, I'm aware of that, it can make the background thread sleep for up to 200msecs before the sound is actually ready (in reality it's never more than a couple of iterations). The point is it works, and I don't see any callbacks for SoundPool (pre 2.2 / SoundPool.OnLoadCompleteListener) to let you know when a sound sample is ready to play. If anyone can enlighten us that would be brilliant. You could look into using MediaPlayer for longer samples, the above I just used for quick sound FX but that doesn't sound like a good fit for your case. Richard On 26 Jan 2011, at 01:06, Steve wrote: > 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 -- 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
