PulseAudio output for SDL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

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

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

I wrote this using the simple synchronous API of PulseAudio, and it
seems to work just fine.

I’ve tested this on Ubuntu Feisty against: Abuse, Enigma, Frozen Bubble,
Heroes, Maelstrom, Neverball, Nexuiz and VisualBoy Advance. I’ve seen no
problems in my testing. Let me know about your results!

Best regards,

  • – St?phan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGJTDlcFUq0gzqDwQRAqNOAJ9MT2Rn1p8ygX3w+YdDsDpxt7ZcfACfXi+t
asaQsv6pV/XZz+iSJu8+ArE=
=mnOD
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdlpulse.patch
Type: text/x-patch
Size: 16093 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070417/9c70a342/attachment.bin

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

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.

Note that PulseAudio has an ALSA plugin, which redirects output from
ALSA applications to the PulseAudio daemon. This plugin is pretty
popular with PulseAudio users, so if SDL were to try ALSA first, it
would always succeed and the native PulseAudio driver would likely
never actually get used.
Nor the games; to my experience, the ALSA plugin for PulseAudio breaks
SDL quite a lot. Locally I set SDL to use ESounD instead, which works
fine, with ALSA I ended up taking down my whole box.On Wed, 18 Apr 2007 14:10:35 +0200 CJ van den Berg wrote:


Diego “Flameeyes” Petten?
http://farragut.flameeyes.is-a-geek.org/
-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070418/d028e3dd/attachment.pgp

-----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! :slight_smile:

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

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

  • – St?phan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGJitocFUq0gzqDwQRAgVlAJsEYWavlXzKey5uDH33C2LqVqWIigCgpKjc
UlS+Y1vkDziq+1dDhJHjsEc=
=p39W
-----END PGP SIGNATURE-----

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

This is in SDL 1.2 now, as of svn revision #3020.

It’ll need a rewrite for the 1.3 branch, as all audio drivers get; I’ll
put that on my TODO list for later.

Also, I have SDL favoring ALSA and OSS still. I would like for the ALSA
target to decide if the ALSA driver is really PulseAudio emulation (some
reliable device name?), and #if SDL_AUDIO_DRIVER_PULSE, fail so the
PulseAudio target can talk directly to the sound daemon instead.

Users that want Pulse all the time can export SDL_AUDIODRIVER=pulse to
use it directly in the meantime.

–ryan.