Ryan C. Gordon icculus at
Tue Jun 25 07:18:09 EDT 2002

Well, it's almost certainly memory corruption. In my case, we hit the
audio callback once, and then deadlock when trying to grab the mutex a
second time:

(gdb) p *audio->mixer_lock
$13 = {id = {__m_reserved = -16711936, __m_count = -16711936,
__m_owner = 0x0, __m_kind = 0, __m_lock = {__status = -1082130880,
__spinlock = 16777472}}, recursive = 16777472, owner = 256}

I dunno. Looks scribbled upon to me.

The corruption is NOT in the converter in question (cut16BitSysTo8Bit).
Commenting it out gives equivalent results.

Aha! Here's the problem (SDL_sound.c, line 575):

     internal->buffer_size = sample->buffer_size / internal->sdlcvt.len_mult;

We do this in three places (sample creation, decodeall, and
setbuffersize). We're assuming that sdlcvt.len_mult is an _integer_ that
is >= 1. This is no longer true. The first test has len_mult set to 0.5.

This means that WAV_read will read 32k into a 16k buffer.

We also have sample->buffer and internal->buffer as the same memory
address, since SDL does the audio conversion in-place. SDL_sound, inside
the decoders, doesn't make this promise, so if we need to change it in the
base of the library it won't break anything else.

Historically, len_mult was meant to be a guide to let you know if you
needed more memory allocated than your original sound data required.
Should we deviate from SDL's current behaviour? Thoughts? Patches?  :)


More information about the sdlsound mailing list