[SDL] SDL 1.3 audio update...

Ryan C. Gordon icculus at icculus.org
Fri Sep 1 00:59:59 PDT 2006

(long email, sorry.)

Okay, lots of SDL 1.3 work on the audio subsystem hit Subversion today. 
I'm still doing the work to add 32-bit datatypes in this batch.

First, SDL_LoadWAV() now handles float32 and int32 .wav files. On this 
box (Linux/amd64 with ALSA), I can use the loopwave.c test on a float32 
.wav file and it plays fine.

The following backends were updated. Please note that most of these 
systems I can't even compile, let alone test, and way too many had no 
documentation available that I could find...so I made some best-guesses. 
If it broke, send a patch and/or complain loudly.

alsa: int32 and float32 are supported directly in the drivers.
amiga: int32 support added (google suggests AHIST_S32S, etc exist)
baudio: int32 and float32 support added (and some others!)
dart: No 32 bit support, but will now use SDL's converters if device 
opened for anything other than U8 or S16LSB (failure before).
dc: No 32-bit support, but will now use SDL's converters if device 
opened for anything but 8 or 16 bit data (failure before).
dmedia: float32 support, fallbacks for other things (failure before).
macosx: float32 and int32 support added. float32 is the fastpath on Mac 
OS X, and apps should favor it on this platform when possible (but the 
other formats will still work).
macrom: int32/float32 support added. Is OS 9 support going away?
mint: one of the codepaths appears to support int32, based on #defines 
in the headers. The rest I just tried to make sure that unexpected 
AudioSpec values get weeded out. I touched a lot more code than I was 
comfortable with here. Someone should check it: revision #2728.
mme: Added int32 support, since you feed it a .wav header, but I don't 
know if the system can actually handle this. I could also feed it a .wav 
header with float32 support, but I couldn't find any indication that the 
system wouldn't barf on this the same way SDL_LoadWAV did until earlier 
nto: Added int32/float32 ... isn't this just ALSA? Why's it a seperate 
windib: Added int32 (see notes about mme).
windx5: Added int32 (see notes about mme).

Several drivers had clamps added for > 2 channel output, since the 
drivers don't (or don't appear to) support more than stereo output.

bsd, paudio, sun, and ums got no updates, even though they might be able 
to use at least int32. Documentation found on google wasn't clear or 
didn't exist. If they can't handle 32-bit data directly, they'll still 
work if SDL_OpenAudio() requests a 32-bit type...SDL will transparently 
convert as necessary. But it may be performance we're leaving on the 
table because I don't know if it's safe to put a "32" into a field or I 
don't know the magic enum name. People that know: please speak up!

dummy and disk just use whatever. No changes needed.

dsp and dma didn't change: the OpenSound docs suggest that there is 
int32 and float32 support, but either strongly urged you not to use it 
or said the symbols were placeholders. The headers on my Linux box 
didn't have the symbols, so OSS loses out here for now. SDL will convert 
to 16-bit at a higher level in these cases.

Others, like esd, arts, and nas, didn't change because they don't 
support 32-bit data and seemed well written (higher level will convert 
data to something it does support before feeding the driver).

Up next:

- move a few fixes that didn't involve 32-bit types back to SDL 1.2.
- debug all this. I still have to fix several converters. If you wrote 
any of these audio backends, I'd appreciate you looking at my changes 
and not making too much fun of me.  :)
- longer term: multiple devices up next, which leads to capture support.


More information about the SDL mailing list