(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
today.
nto: Added int32/float32 … isn’t this just ALSA? Why’s it a seperate
backend?
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.
–ryan.