Android :: Plans For Improving The Sound Pool System

I have been finishing off the port of one of my games to Android, with the last two things being music and sound effects. I have implemented the music system now, using a series of MediaPlayer instances, and that all seems to be working fine (I only need to do limited things with music, just playing, pausing and stopping really). I am now trying to finish of the sound effects, but I am struggling.

1. I am targeting Android 1.6+ and therefore do not have access to the setOnLoadCompleteListener function. What is my best way to wait until all sound effects are loaded? I am thinking my best bet is to load all my sounds, then load a dummy (short, silent) sound, and then sit in a loop attempting to play that sound (and then sleeping for 1ms) until the play returns non zero. Does this sound reasonable? Would it be crazy to do this process for every sound effect I load, as the calling code expects the load function to stall as long as it takes for the load to complete - I am not interested in the sound pool trying to do any async stuff for me, all of my background loading is done in a separate thread, and this thread can stall as long as it likes, as long as it actually loads what I am asking it to.

2. Is there anyway I can find out when a sound effect has finished playing? The games I am porting might have code along the lines of 'play sound effect, wait for it to complete, then fade the screen out and load next context' which on other platforms is easy enough to implement. In OpenAL for example, at the end of each frame I check if the OpenAL state for a given SFX is now stopped, in which case I update the game side sound handle to let it know it's now in the stopped state. But I just can't seem to find a way to achieve the same thing on Android. I am beginning to think my only option would be to (somehow) work out the length of the sample, and then when play is called, set a timer to trigger 100ms after the sample time (100ms to account for any delay in the sound starting), and in the timer function set the game side sfx state to be stopped. Does this sound reasonable? Are there any better ways of handling this?

3. Will a sound pool run out of ids? It seems it have been designed so you have one sound pool per 'level' and after each level you release the pool. This doesn't really fit too well with all my code so I am trying to avoid it. But I notice the documentation states a lot of functions will work even after a sound id is no longer valid (it has stopped for example), the functions won't do anything, but they want break anything. This to me says that id's are never recycled. So are there limits? If so what are the limits?

4. Finally, are there any plans for improving the sound pool system? Ideally I'd like to see it work in a similar way to the other main sound APIs. The reason being I target multiple platforms on the engine side, and have 100% generic game code, so I need to establish a base level interface to the API which will work across the board. This is made very difficult by the SoundPool API being set up to work in a specific way, as opposed to just having reasonable low level functions, and allowing the end user to wrap this up how they see fit. I like the fact there are high level classes around to handle this work of work, and I agree these should remain, but I'd like to see something perhaps lower level exposed, which the SoundPool could wrap around perhaps.