[sdlsound] Problem with Playsound

Corona688 tsm at accesscomm.ca
Wed Oct 23 11:49:44 EDT 2002

"Ryan C. Gordon" wrote:

> 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.

Ah, I see.  My bad.

> 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.

Yup, my bad.  Sorry.  Just fishing for something to fix.

 Experimenting with LibModPlug in WinCE outside of SDL_sound has convinced me
that the mysterious clicking is NOT due to the CPU being unable to keep up...
I can run my program at 16-bit stereo 44KHz just fine AND get a good screen
refresh rate.

Meaning that unless I'm highly mistaken, the problem's in the SDL_sound code
itself.  Might be the same problem that bit us with LibModPlug - the
Armstrong's utter refusal to accept odd memory addresses for anything but byte
reads.  If it's an error of that kind it will compile without complaint, but
it'll truncate the last bit from the address when running, causing
who-knows-what havoc.

I haven't done much with the SDL_sound code itself - so portable in general
that I haven't had to touch it.  Do you know of any likely spots to check out
for this kind of memory access?

> 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.

Sweet!  :)

> 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.

More information about the sdlsound mailing list