[pulseaudio-discuss] [SDL] PulseAudio output for SDL

[Stéphan Kochen]

-----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-----