Why do you say it's not a public API?
On Sun, Feb 15, 2009 at 10:09 PM, Jon Colverson <[email protected]> wrote: > The presence of SoundPool in the SDK causes a bit of a dilemma for > those of us developing games. On the one hand, it's not a public API > and it might go away or change in future releases, breaking our games > and annoying our users. On the other hand, it does provide a > noticeable performance improvement over using MediaPlayers, and I have > to assume that my competitors will be using it to eek out as much > performance as possible. > > So after changing my mind a few times, I've decided that I will use > SoundPool in my game, but I've come up with a compromise that will > hopefully stop it from breaking if the API changes later: Attached is > a set of classes that wrap SoundPool by loading the class dynamically > at runtime via reflection, and if it isn't found or doesn't support > the expected methods, falls back on a wrapper around MediaPlayer that > implements a (very) small subset of the SoundPool API. It's very basic > and only supports playing non-looping sounds with variable volume, so > it won't help if you need pitch changing, but if you just want > SoundPool for its performance then it might be useful. > > Here's how to use it: > int maxStreams = 16; > ISoundPool sp = SoundPoolProxy.bestSoundPool(maxStreams, > AudioManager.STREAM_MUSIC, 100); > int s = sp.load(context, resource, 0); > float leftVolume = 1, rightVolume = 1; > sp.play(s, leftVolume, rightVolume, 0, 0, 1); > > Some caveats: > As mentioned by others, if you try to play more than maxStreams sounds > at the same time then SoundPool will deadlock. > It might still break if the API changes in the future without changing > the method signatures (so the parameters have different meanings). If > that causes an exception in SoundPool then my wrapper will throw a > RuntimeException up to you, so you could catch them if you'd prefer > for sound to fail silently instead of crashing your app. > Calling SoundPool's methods via reflection involves a certain amount > of overhead. In my tests the average call time was 3.439ms, compared > with 3.088ms when calling SoundPool directly, so an 11% overhead. > > -- > Jon > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
