SDL audio thread

SDL Development
1

Sometimes I find that if the application segfaults, it does not crash. I
have tried to force this condition for testing purposes - using this
all-powerful command which does the all-impressive

*(int *)NULL = BigLong (0x55303052); // W00T

(read SDL_SwapBE32 for BigLong, except that BigLong will extend signs and
SDL won’t, a minor nit about SDL’s byteorder code…)

Okay, seriously now. =) It basically doesn’t die, and here’s the
backtrace:

#0 0x400eba9e in sigsuspend () from /lib/libc.so.6
#1 0x4008e659 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x4008b8b1 in pthread_join () from /lib/libpthread.so.0
#3 0x40061dff in SDL_SYS_WaitThread () from /usr/lib/libSDL-1.2.so.0
#4 0x40061be0 in SDL_WaitThread () from /usr/lib/libSDL-1.2.so.0
#5 0x4002ca48 in SDL_AudioQuit () from /usr/lib/libSDL-1.2.so.0
#6 0x4002b80e in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#7 0x4002b87c in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#8 0x4002c0e4 in SDL_Error () from /usr/lib/libSDL-1.2.so.0
#9 0x4008ed34 in pthread_sighandler () from /lib/libpthread.so.0
#10 0x400eb8d8 in sigaction () from /lib/libc.so.6
#11 0x08055dc2 in Cmd_ExecuteString (text=0xbffff5ac “crash”) at cmd.c:882

Now threads aren’t my area of expertise, but it looks to me like SDL isn’t
being very successful at killing the sound thread. Is there a workaround
or something I may be doing wrong? I’m using SDL 1.2.2 here.–
Joseph Carter Free software developer

$you = new YOU;
honk() if $you->love(perl)
– Seen on Slashdot

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011031/16cf71f9/attachment.pgp

2

Joseph Carter wrote:

(read SDL_SwapBE32 for BigLong, except that BigLong will extend signs and
SDL won’t, a minor nit about SDL’s byteorder code…)

SDL’s byteswap macros aren’t supposed to sign-extend. It’s not a bug

3

Of course not, it’s supposed to do byte swabbing. That’s not the point,
the unkillable program which locks the system hard is…On Wed, Oct 31, 2001 at 06:13:21PM +0100, Mattias Engdegard wrote:

(read SDL_SwapBE32 for BigLong, except that BigLong will extend signs and
SDL won’t, a minor nit about SDL’s byteorder code…)

SDL’s byteswap macros aren’t supposed to sign-extend. It’s not a bug

–
Joseph Carter Free software developer

do {
:
} until (HELL_FREEZES_OVER);

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011031/87dadeed/attachment.pgp

4

Okay, seriously now. =) It basically doesn’t die, and here’s the
backtrace:

#0 0x400eba9e in sigsuspend () from /lib/libc.so.6
#1 0x4008e659 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x4008b8b1 in pthread_join () from /lib/libpthread.so.0
#3 0x40061dff in SDL_SYS_WaitThread () from /usr/lib/libSDL-1.2.so.0
#4 0x40061be0 in SDL_WaitThread () from /usr/lib/libSDL-1.2.so.0
#5 0x4002ca48 in SDL_AudioQuit () from /usr/lib/libSDL-1.2.so.0
#6 0x4002b80e in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#7 0x4002b87c in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#8 0x4002c0e4 in SDL_Error () from /usr/lib/libSDL-1.2.so.0
#9 0x4008ed34 in pthread_sighandler () from /lib/libpthread.so.0
#10 0x400eb8d8 in sigaction () from /lib/libc.so.6
#11 0x08055dc2 in Cmd_ExecuteString (text=0xbffff5ac “crash”) at cmd.c:882

Now threads aren’t my area of expertise, but it looks to me like SDL isn’t
being very successful at killing the sound thread. Is there a workaround
or something I may be doing wrong? I’m using SDL 1.2.2 here.

Is the crash occurring while the audio mutex is held by the main application?
Quitting the audio sets a flag and waits for the audio thread to notice the
flag and shut itself down. If the audio thread is waiting on the audio lock
mutex, then it won’t ever notice the shutdown request.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

5

I barely understand what a mutex is, but I need to unlock the audio thread
before the thing will quit? Hmm, kinda hard to do since SDL takes over
signal handling, but I know how to handle that. Why doesn’t SDL unlock
the audio if it needs to be in order to cope with this problem? We are
talking about crash conditions here.On Fri, Nov 02, 2001 at 11:45:20AM -0800, Sam Lantinga wrote:

Okay, seriously now. =) It basically doesn’t die, and here’s the
backtrace:

#0 0x400eba9e in sigsuspend () from /lib/libc.so.6
#1 0x4008e659 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x4008b8b1 in pthread_join () from /lib/libpthread.so.0
#3 0x40061dff in SDL_SYS_WaitThread () from /usr/lib/libSDL-1.2.so.0
#4 0x40061be0 in SDL_WaitThread () from /usr/lib/libSDL-1.2.so.0
#5 0x4002ca48 in SDL_AudioQuit () from /usr/lib/libSDL-1.2.so.0
#6 0x4002b80e in SDL_QuitSubSystem () from /usr/lib/libSDL-1.2.so.0
#7 0x4002b87c in SDL_Quit () from /usr/lib/libSDL-1.2.so.0
#8 0x4002c0e4 in SDL_Error () from /usr/lib/libSDL-1.2.so.0
#9 0x4008ed34 in pthread_sighandler () from /lib/libpthread.so.0
#10 0x400eb8d8 in sigaction () from /lib/libc.so.6
#11 0x08055dc2 in Cmd_ExecuteString (text=0xbffff5ac “crash”) at cmd.c:882

Now threads aren’t my area of expertise, but it looks to me like SDL isn’t
being very successful at killing the sound thread. Is there a workaround
or something I may be doing wrong? I’m using SDL 1.2.2 here.

Is the crash occurring while the audio mutex is held by the main application?
Quitting the audio sets a flag and waits for the audio thread to notice the
flag and shut itself down. If the audio thread is waiting on the audio lock
mutex, then it won’t ever notice the shutdown request.

–
Joseph Carter Free software developer

  • cesarb wonders if in less than a week Carmack will end up receiving in
    e-mail a courtesy copy of a version of the Quake source which is four
    times faster than what went out of his virtual hands…

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011102/543ac3dd/attachment.pgp

6

I barely understand what a mutex is, but I need to unlock the audio thread
before the thing will quit? Hmm, kinda hard to do since SDL takes over
signal handling, but I know how to handle that. Why doesn’t SDL unlock
the audio if it needs to be in order to cope with this problem? We are
talking about crash conditions here.

To simplify the question… what are the other threads in the program doing?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

7

There is exactly one other thread, and it’s doing everything. At the time
of crash, it’s dying. ;)On Fri, Nov 02, 2001 at 12:41:20PM -0800, Sam Lantinga wrote:

I barely understand what a mutex is, but I need to unlock the audio thread
before the thing will quit? Hmm, kinda hard to do since SDL takes over
signal handling, but I know how to handle that. Why doesn’t SDL unlock
the audio if it needs to be in order to cope with this problem? We are
talking about crash conditions here.

To simplify the question… what are the other threads in the program doing?

–
Joseph Carter Free software developer

Knghtbrd: I’d love to see support for xor crosshairs…
Mercury: you’re on quack.
Knghtbrd: You’re the dealer…
*** Knghtbrd is now known as QuackDealer

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011102/864bd0a7/attachment.pgp

8

Hum. I don’t know what’s going on. Does it happen on every system?
You could post a link to a sample application that I can build and run
and see if it happens here.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Fri, Nov 02, 2001 at 12:41:20PM -0800, Sam Lantinga wrote:

I barely understand what a mutex is, but I need to unlock the audio thread
before the thing will quit? Hmm, kinda hard to do since SDL takes over
signal handling, but I know how to handle that. Why doesn’t SDL unlock
the audio if it needs to be in order to cope with this problem? We are
talking about crash conditions here.

To simplify the question… what are the other threads in the program doing?

There is exactly one other thread, and it’s doing everything. At the time
of crash, it’s dying. :wink:

9

Yeah, it happens on win32 systems too, though both had NVidia cards that I
noticed. -nosound DOES fix it. I think I need to audit the code on a
more and see if I can restructure the locking and callback and stuff to
try and see if I can find a case which does not lock. I am almost certain
that I can trap my own signals and run the normal shutdown functions, but
I worry about that on win32 - plus the shutdown function does more or less
what SDL does - SDL_Quit. It does run S_Shutdown () first which pauses
audio, unlocks it, etc. I really feel SDL should do that itself.On Sat, Nov 03, 2001 at 09:52:58AM -0800, Sam Lantinga wrote:

There is exactly one other thread, and it’s doing everything. At the time
of crash, it’s dying. :wink:

Hum. I don’t know what’s going on. Does it happen on every system?
You could post a link to a sample application that I can build and run
and see if it happens here.

–
Joseph Carter Free software developer

“I wonder if this is the first constitution in the history of mankind
where you have to calculate a square root to determine if a motion
passes. :-)”
– Seen on Slashdot

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011103/4fb06f7a/attachment.pgp

10

If you figure out a set of things that need to happen to cleanly shut
down the audio, please let me know and I’ll add them to the cleanup.

Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Sat, Nov 03, 2001 at 09:52:58AM -0800, Sam Lantinga wrote:

There is exactly one other thread, and it’s doing everything. At the time
of crash, it’s dying. :wink:

Hum. I don’t know what’s going on. Does it happen on every system?
You could post a link to a sample application that I can build and run
and see if it happens here.

Yeah, it happens on win32 systems too, though both had NVidia cards that I
noticed. -nosound DOES fix it. I think I need to audit the code on a
more and see if I can restructure the locking and callback and stuff to
try and see if I can find a case which does not lock. I am almost certain
that I can trap my own signals and run the normal shutdown functions, but
I worry about that on win32 - plus the shutdown function does more or less
what SDL does - SDL_Quit. It does run S_Shutdown () first which pauses
audio, unlocks it, etc. I really feel SDL should do that itself.

11

SDL_LockAudio was the culprit. Since it’s quite possible that it may
never be unlocked if something dies while the lock is in place, I would
recommend that you don’t wait for it to unlock before shutting it down,
implement timeouts for SDL_WaitThread, or unlock it yourself before trying
to shut it down.

As for Project Twilight’s sound code, I can only apologize to the world at
large and beg forgiveness. After tracing each function spanning the five
files of the sound subsystem (which was written for writing to a DMA
buffer), I discovered that it was locking audio at the start and leaving
it that way until after S_PaintChannels was called. It was then unlocked
and relocked immediately to give the callback thread a chance to run once
or so (I assume…) What the hell posessed me to think this was a bright
idea, I have no idea. At the time I did this, I hadn’t yet read John’s
book and was at best clueless. I believe someone suggested that I needed
to do that, and so I did.

But that wasn’t the only moronic turn of events I had to worry about. No,
indeed not. As it turns out, the audio callback I was using was one I
took from QuakeForge wholesale. It calls S_PaintChannels in the callback
as well as just before it, and when you fix the above braindamage (which
they have as well) it causes sound to be absolutely silent for about a
second or so and then just be there in current sync. Like it started
writing late. I can’t explain what the hell the person who wrote it must
have been thinking but basically it basically shouldn’t be there and the
whole thing runs much more sanely without it.

Of course now that I actually understand this mess, and more importantly
how much simpler if the mixing were just done in that second thread, it
would be prudent to scrap the existing sound code entirely and write a
clean version which took half the code (and half the memory…) Consider
this another endorsement for Programming Linux Games, etc, etc…On Sat, Nov 03, 2001 at 09:21:14PM -0800, Sam Lantinga wrote:

If you figure out a set of things that need to happen to cleanly shut
down the audio, please let me know and I’ll add them to the cleanup.

–
Joseph Carter Free software developer

lilo: well then, you are probably a responsible thinker.
Welcome to a very small club.
Overfiend: welcome me when you join :slight_smile:

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011104/98b2baa3/attachment.pgp