> 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.
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. :)
> 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.
--ryan.
