Bug in SDL_OpenAudio()?

I just want to make sure this is incorrect behaviour:

We’re not supposed to be able to call SDL_OpenAudio() twice in a row,
right? Since the emu10k1 drivers for Linux allow multiple opens of
/dev/dsp, both calls succeed, but I presume this confuses internal state
(indeed, it looks like we scribble over the filehandle for the original
opening of /dev/dsp on the second open call).

Should I send a patch that manages a flag in SDL_OpenAudio and
SDL_CloseAudio to prevent multiple opens? Or at least have it call
SDL_CloseAudio at the start of SDL_OpenAudio, to keep the state sane.

–ryan.

Ryan C. Gordon wrote:

I just want to make sure this is incorrect behaviour:

We’re not supposed to be able to call SDL_OpenAudio() twice in a row,
right? Since the emu10k1 drivers for Linux allow multiple opens of
/dev/dsp, both calls succeed, but I presume this confuses internal state
(indeed, it looks like we scribble over the filehandle for the original
opening of /dev/dsp on the second open call).

Should I send a patch that manages a flag in SDL_OpenAudio and
SDL_CloseAudio to prevent multiple opens? Or at least have it call
SDL_CloseAudio at the start of SDL_OpenAudio, to keep the state sane.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

uh, why not just use the filedescriptor as the flag…and set it to -1 initially…
since -1 is invalid, you can test for that in SDL_OpenAudio to see if it was already open or not
and reset it back to -1 in SDL_CloseAudio.–
-==-
Jon Atkins
http://jonatkins.org/

“Ryan C. Gordon” wrote:

We’re not supposed to be able to call SDL_OpenAudio() twice in a row,
right?

Right, I see no reason to allow that

Should I send a patch that manages a flag in SDL_OpenAudio and
SDL_CloseAudio to prevent multiple opens? Or at least have it call
SDL_CloseAudio at the start of SDL_OpenAudio, to keep the state sane.

I think both solutions are acceptable, with a small preference for the
former

uh, why not just use the filedescriptor as the flag…and set it to -1 initially…
since -1 is invalid, you can test for that in SDL_OpenAudio to see if it was already open or not
and reset it back to -1 in SDL_CloseAudio.

…because then I might be reporting this bug for other drivers in the
future?

–ryan.

I think both solutions are acceptable, with a small preference for the
former

I’ll send a patch (for the former) later today.

–ryan.