Hi,
I wrote to the list about a vague crash my Doom port, The Eternity Engine,
was suffering on an x86 Mac machine running WinXP a couple of months ago and
we couldn’t really get anywhere at that point. However, I have now been able
to rule out any fault of my own by creating a logfile that is written to
during my audio callback routine (a supposed no-no but it works fine).
At the start of the postmix callback (I_SDLUpdateSound,
http://eternity.mancubus.net/svn/trunk/eternity/source/sdl/i_sound.c), it
wrote this:
update sound start: ud=00000000, s=023A6050, len=8192; lo=023A6050,
ro=023A6052, le=023A8050
ud is the userdata pointer, s is the stream pointer, len is the length (all
of this data is passed to me by SDL_Mixer). lo is the “leftout” pointer
(left audio channel), ro is rightout, and le is leftend, or the value of
leftout at which we should stop writing any data (the value has been
appropriately calculated as s + 8192).
However, the program crashes while the update loop is still running and is
writing to the 3016th or 3017th byte of the buffer:
leftout = 023A6C18, rightout = 023A6C1A
channel 0: dl=-203, dr=-209, step=16384, stepremainder=49152, data=010B9804
channel 1: dl=-1251, dr=-1257, step=16384, stepremainder=0, data=010B4C17
channel 2: dl=-3880, dr=-3138, step=16384, stepremainder=32768,
data=010C1C54
channel 3: dl=-20372, dr=-15623, step=16384, stepremainder=0, data=010C1978
channel 4: dl=-2329, dr=-1495, step=16384, stepremainder=49152,
data=010C1584
If the I_SDLUpdateSound call had proceeded beyond the final write to the
audio buffer performed after the last log message here, there would be
another leftout/rightout message, and if it had finished the update to the
buffer, the message “end of sound update” would appear. Neither message
appears, proving the program crashed at this point.
So, the buffer that I have been handed by SDL_mixer has been invalidated by
something, or I am being lied to about the amount of available space in the
buffer. One way or another, I believe this is a bug in SDL_mixer, because
the PrBoom source port uses the same update loop as we do, but they pipe the
sound directly into SDL’s raw audio buffers. This port however does not
experience this crash.
I hope this prompts some ideas on what is going on here.
Yours,
James Haley_________________________________________________________________
Don?t miss your chance to WIN $10,000 and other great prizes from Microsoft
Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/