-----BEGIN PGP SIGNED MESSAGE-----
[I wrote this concept in the afternoon, but my uni blocks smtp. Some of
this reiterates what’s already been said.]
Ryan C. Gordon schreef:
Today, I spent some time to write a simple PulseAudio driver for SDL.
You’ll find a patch against the SDL 1.2 subversion branch attached.
(I hope I didn’t duplicate any effort. I couldn’t find anything.)
No duplication that I’m aware of. Thanks for the patch! I’ll try to get
this tested shortly, and included in Subversion.
Okay, good. No problem. And thank you!
Also, in terms of SDL doing the right thing, I assume it should favor
PulseAudio over arts and esd, but we generally try to favor real
hardware over sound daemons when we can…I know PulseAudio lists “low
latency” in its feature set, but too many years of fighting esound has
made me skeptical that we should favor PulseAudio over ALSA when
choosing an audio target. Obviously, in that case, if ALSA isn’t
available (user has no direct permission to hardware but PulseAudio
does, or ALSA can’t handle multiple opens and PulseAudio has the
device), we can fallback to PulseAudio, or it can be forced by the user.
Note that my whole understanding of PulseAudio came from Wikipedia after
I read your email, so any enlightenment here is appreciated.
I was not sure where to put it, exactly. My reasoning for putting it
before ALSA was because I personally have the PulseAudio plugin for ALSA
as my default ALSA ‘card’. However, that plugin seems to be a tad buggy
at the moment, and SDL was favoring it.
My setup may not be the most common, though.
Besides the ALSA plugin, PulseAudio also has OSS emulation. But that is
similar to ESD’s: using a ‘padsp’ utility. So it’s no problem to favor OSS.
Finally, there’s ESD emulation. Though I couldn’t get SDL working nicely
with PulseAudio and the existing ESD output. (It slowed things down a
lot.) I agree that PulseAudio should definitely be in front of this.
Though I was wondering, is there any reason why most audio drivers seem
to use asynchronous mode and then poll the destination device in their
PlayAudio function? (Instead of simply using synchronous mode and
blocking on write.)
Probably a few reasons: older, buggy drivers, cut-and-paste between SDL
audio targets that did it one way or another, etc. In the case of the
OSS (“dsp”) target, older kernels would block the process in the open()
call if another app was already using /dev/dsp, and not return control
to SDL until the first app closed the device…if that first app was,
say, your media player, you could possibly never close the device, and
the SDL app would inexplicably hang in SDL_OpenAudio()…unless you
opened with O_NONBLOCK.
A lot of other SDL targets were cut-and-pasted from there.
Since the audio device i/o happens in its own thread in most cases, it’s
perfectly safe to just block if the underlying system isn’t broken, as
far as I can tell.
Okay, that’s good to know. Thanks for the info.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----