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

Ryan C. Gordon icculus at icculus.org
Wed Apr 18 01:52:48 PDT 2007

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


More information about the pulseaudio-discuss mailing list