-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[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. :)
- -- St?phan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGJitocFUq0gzqDwQRAgVlAJsEYWavlXzKey5uDH33C2LqVqWIigCgpKjc
UlS+Y1vkDziq+1dDhJHjsEc=
=p39W
-----END PGP SIGNATURE-----
