[SDL] endianness in SDL_audio.c

Albert Cahalan 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) */
> [snip]
> #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 mailing list