[SDL] endianness in SDL_audio.c
albert at users.sf.net
Thu Jan 27 10:40:25 PST 2005
On Thu, 2005-01-27 at 19:44 +0100, Patrice Mandin wrote:
> Le Thu, 27 Jan 2005 10:49:25 -0500
> Albert Cahalan <albert at users.sf.net> a écrit:
> > The root of the problem is that developers use AUDIO_S16
> > when they should be using AUDIO_S16SYS. I recently fixed
> > Tux Paint, then patched up a wiki somewhere to warn about
> > the issue. App developers are pretty much led into using
> > AUDIO_S16 instead of the correct AUDIO_S16SYS.
> > As far as I can tell, one should never use AUDIO_S16 in
> > app code. It should be removed from the headers I think.
> > SDL_mixer.h has a MIX_DEFAULT_FORMAT that really should be
> > defined as AUDIO_S16SYS.
> I agree. Seeing something like this in SDL_audio.h:
> /* Audio format flags (defaults to LSB byte order) */
> #define AUDIO_U16 AUDIO_U16LSB
> #define AUDIO_S16 AUDIO_S16LSB
> is not ok, when you have AUDIO_[U|S]16SYS correctly defined for
> endianness. And the comment about the default byte order should be
> removed. Why default to LSB byte order ?
> SDL_wave.c should also be patched, to change AUDIO_S16 to AUDIO_S16LSB for
> spec->format. Better: check that MS_ADPCM_decode() and IMA_ADPCM_decode()
> functions really decode in AUDIO_S16LSB, not in the native format. I
> wonder if it decodes (wrongly!) to AUDIO_S16MSB on a big endian machine,
> whereas the spec->format is set to AUDIO_S16[LSB].
That's for *.wav file decoding, right?
If you flipped that, I think you'd undo the proposed fix
and break the Tux Paint in CVS. I also think that a *.wav
file should end up in native byte order so that it can
be operated on in various ways.
Tux Paint loads *.wav files via Mix_LoadWAV, then plays
them via Mix_PlayChannel. AUDIO_S16SYS is used and works.
Previously, AUDIO_S16 was used and did not work on ppc Linux.
More information about the SDL