We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 327

Summary: SDL_BuildAudioCVT add useless endianness conversion in some cases
Product: SDL Reporter: Patrice Mandin <patmandin>
Component: audioAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 1.2.9   
Hardware: All   
OS: All   

Description Patrice Mandin 2006-09-14 17:50:45 UTC
Marked for 1.2.9, but still present in 1.2.x-svn, maybe fixed in 1.3 due to heavy changes.

When I build an audio conversion from 16 bits big endian (AUDIO_S16MSB) to 8 bits (AUDIO_S8), SDL adds a useless (and thus buggy for the end result) endianness conversion (the first filter added).

It happens because AUDIO_S16MSB = 0x1010 and AUDIO_S8 = 0x0008, and the masked values with 0x1000 fails in this case, whereas it is not a problem for AUDIO_S16LSB = 0x0010.

Shouldn't the endianness filter be present only when both formats (src and dest) are 16bits? Or are there other cases where this conversion should happen?
Comment 1 Ryan C. Gordon 2006-09-14 19:34:10 UTC
This is definitely fixed in 1.3, since the datatype conversion code is completely rewritten, but I'll look at this for 1.2.

--ryan.
Comment 2 Patrice Mandin 2006-09-15 16:43:42 UTC
This small check fixed the problem for me. It just checks both src and dst are 16bits to convert endianness. I will commit it if there are no problems.

@@ -1374,12 +1375,14 @@

        /* First filter:  Endian conversion from src to dst */
        if ( (src_format & 0x1000) != (dst_format & 0x1000)
-            && ((src_format & 0xff) != 8) ) {
+            && ((src_format & 0xff) == 16) && ((dst_format & 0xff) == 16)) {
                cvt->filters[cvt->filter_index++] = SDL_ConvertEndian;
        }
Comment 3 Ryan C. Gordon 2006-09-15 17:55:17 UTC
Go ahead.

--ryan.