A bug in the current SDL esd handling sparked a very long and interesting
discussion of the inherent problems with trying to anticipate when ESD is
running and compensate for potential problems with device access conflicts.
The problem finally boiled down to the fact that any program that blocks
until the device is ready should be considered buggy, and that the user
can configure SDL to use ESD as it’s primary audio output if this is
desired.
So… new behavior as of SDL 1.0.5 and 1.1.0 will be that SDL will try
to use the primary audio output if possibe, falling back to secondary
audio outputs if they are available, and finally try to connect to ESD
as a fallback.
This behavior is completely configurable via environment variables,
and in new SDL 1.1.0, via config variables.
If you want SDL try to use DMA audio, falling back to DSP, then ESD:
export SDL_AUDIODRIVER=dma
If you want SDL to use ESD, then falling back to DSP audio:
export SDL_AUDIODRIVER=esd
You can put that in your FAQ and smoke it.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
This reminds me of another question: will SDL try to use
/dev/dsp and friends even if the application is started
over a X11 network connection ?
I’ve briefly looked over the audio sources but didn’t
see a test for this situation.
MarkusOn 09-Feb-2000 Sam Lantinga wrote:
A bug in the current SDL esd handling sparked a very long and interesting
discussion of the inherent problems with trying to anticipate when ESD is
running and compensate for potential problems with device access conflicts.
The problem finally boiled down to the fact that any program that blocks
until the device is ready should be considered buggy, and that the user
can configure SDL to use ESD as it’s primary audio output if this is
desired.
So… new behavior as of SDL 1.0.5 and 1.1.0 will be that SDL will try
to use the primary audio output if possibe, falling back to secondary
audio outputs if they are available, and finally try to connect to ESD
as a fallback.
This behavior is completely configurable via environment variables,
and in new SDL 1.1.0, via config variables.
If you want SDL try to use DMA audio, falling back to DSP, then ESD:
export SDL_AUDIODRIVER=dma
If you want SDL to use ESD, then falling back to DSP audio:
export SDL_AUDIODRIVER=esd
You can put that in your FAQ and smoke it.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----
Hmm - I’d say that SDL should never talk to the soundcard
directly in such a case, regardless of SDL_AUDIODRIVER.
Am I missing something ?
Markus
---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----
3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:
This reminds me of another question: will SDL try to use
/dev/dsp and friends even if the application is started
over a X11 network connection ?
Yes.
In addition to the display variable, if you want networked audio,
set:
SDL_AUDIODRIVER=esd
ESPEAKER=???
Yes, some configurations set the ESPEAKER environment variable
to the local system anyway.
You as a developer are free to set environment variables or config
variables yourself, but I don’t want to assume a particular configuration.
I’ve gotten in trouble with that before.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> On 09-Feb-2000 Sam Lantinga wrote:
This reminds me of another question: will SDL try to use
/dev/dsp and friends even if the application is started
over a X11 network connection ?
Yes.
In addition to the display variable, if you want networked audio,
set:
SDL_AUDIODRIVER=esd
ESPEAKER=???
Hmm - I’d say that SDL should never talk to the soundcard
directly in such a case, regardless of SDL_AUDIODRIVER.
Am I missing something ?
–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Indeed - SDL should interpret DISPLAY to determine whether
it is legal to try dsp & dma at all.
Interpretation of ESPEAKER belongs strictly to esd.
Markus
---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----
3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:
Yes, some configurations set the ESPEAKER environment variable
to the local system anyway.
But that’s what I meant: SDL should only try esd (and neither
dsp nor dma) in such a case.
Okay, good point.
The latest CVS code will use ESD if the ESPEAKER environment variable is
set and no SDL_AUDIODRIVER variable has been specified.
Interpretation of ESPEAKER belongs strictly to esd.
I’m assuming that if ESPEAKER is set, then you want to use ESD,
and leave the interpretation of that variable to esd.
This gives greater flexibility since you can configure ESD to
send to any host, and send the graphics to any other host, or
leave audio on the same system, etc. etc.
Yes, some configurations set the ESPEAKER environment variable
to the local system anyway.
But that’s what I meant: SDL should only try esd (and neither
dsp nor dma) in such a case.
Okay, good point.
The latest CVS code will use ESD if the ESPEAKER environment variable is
set and no SDL_AUDIODRIVER variable has been specified.
This smells like a hack.
Indeed - SDL should interpret DISPLAY to determine whether
it is legal to try dsp & dma at all.
The audio and video portions of the library are strictly separated.
Interpretation of ESPEAKER belongs strictly to esd.
The name DISPLAY is purely historical and describes a
network connection.
Instead of the current
1.0.5: If the ESPEAKER environment variable is set, use ESD
I think it should say
1.0.5: If DISPLAY describes a non-local connection don't try
to open the local soundcard (like /dev/dsp or DMA)
Suggestion? (Other than looking at DISPLAY)
I’m no network guru - any other opinions ?
Markus
---- Markus F.X.J. Oberhumer <@Markus_F.X.J_Oberhum> ----
---- http://wildsau.idv.uni-linz.ac.at/mfx/ ----
---- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----
3 WARPS TO URANUSOn 09-Feb-2000 Sam Lantinga wrote:
