[sdlsound] Problem with Playsound

[Ryan C. Gordon]

> Playsound makes one major assumption when it opens an audio device -
> that the format it requests is the device it gets.  Under the vast
> majority of situations, this is true;  however, under Windows CE, it is
> not.

It isn't assuming. Playsound _needs_ to open the audio device with
parameters that match the audio file, and SDL translates on-the-fly if it
can't get that exact format from the audio device. This is compliant with
the SDL API documentation.

The option is to convert in playsound, or convert in SDL, but either way
it's going to be a CPU hit. My assumption is that SDL is more qualified to
accelerate this action on a given platform than playsound is.

> WinCE demands an audio buffer size of precisely 11028 samples at 44Khz
> 16-bit stereo.  Why?  Beats the hell out of me.  This could easily be
> the explanation of the mysterious clicking I thought was due to the
> processor being unable to keep up with the decoder;  I could minimize
> it, but I could never get rid of it entirely.

It's likely that a given audio format will be 16-bit/44KHz to begin
with...as for the fragment size, SDL will just keep running the callback
if we give it less than it needs each time.

While it isn't good to have to convert the data between formats, the real
CPU killer is the floating point needed for decoding MP3s and Oggs. i
thought that mpglib was integerized (since I heard somewhere that it works
well on the StrongARM chip), but it doesn't appear to be when looking at
the source.

xiph.org just released an integerized Vorbis decoder, called Tremor. I
haven't looked, but if it has the same API as the floating point
libraries, it might be worth trying it on WinCE for a significant speed
boost.

There is also a GPL'd MP3 integer decoder that has been discussed here
before (madplay? Something like that) ... that is still worth exploring,
if we can get a GPL exception of some sort.

--ryan.