| Summary: | Playing CD-ROM audio tracks fails on Intel Macs | ||
|---|---|---|---|
| Product: | SDL | Reporter: | alun.bestor |
| Component: | cdrom | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED INVALID | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | alun.bestor, sezeroz |
| Version: | HG 2.0 | ||
| Hardware: | PowerPC | ||
| OS: | Mac OS X 10.5 (Intel) | ||
| Attachments: | The quick fix | ||
Created attachment 312 [details]
The quick fix
I noticed this bug too. I performed the quick fix of swapping all the integers read by AudioFilePlayer.c. It works fine.
The music file playing capability of SDL_mixer is great, but CD support is a good backup and 'default' option for games.
The fix seems fine. We hit this issue with our hexen2 macosx port with sdl-1.2, too. So this should be applied to the 1.2 branch along with the trunk. This is a good fix, however SDL 1.3 is no longer supporting reading CD audio. |
SDL_CDPlay fails with return value -6, and produces the error message "LoadFile: Could not create player", instead of playing the specified segment of CD audio. The problem lies in AudioFilePlayer_OpenFile in cdrom/macosx/AudioFilePlayer.c, which according to the header comments was copied from some old sample code for MacOS 9 from Apple's developer website. AudioFilePlayer_OpenFile parses header chunks from an AIFF file to determine whether it's the correct filetype and where the audio data begins in the file. It does so by reading these chunks directly into structs, whose members are unsigned 32-bit integers. This appears to result in an endianness bug on Intel Macs: the integers are being packed in the wrong order. The first line that fails is #257: if (chunkHeader.ckID != 'FORM') { ...because the chunkHeader.ckID on an Intel CPU is actually equivalent to 'MROF'. (Note the use of multi-character constants instead of strings; these are known as fourccs and are a common MacOS programming convention.) There are more related endianness bugs in this function, which affect chunk length checks as well as chunk ID comparisons. These mean that even if the ID comparisons are fixed, the function won't find the correct offset for audio data to begin playing. FWIW there's likely to be more such endianness bugs elsewhere in the copied sample code, which extends into AudioFileReaderThread.c. Apple's developer site has since deprecated this method of CD audio access in favour of Core Audio (introduced in OS X) so it might be worth just ripping out the lot.