Priority of audio devices

SDL Development
1

…so in SDL-1.2, this is the order we try audio devices by default on
Linux, until we find one that is available…

  • /dev/dsp with write()
  • /dev/dsp with mmap()
  • ALSA
  • PulseAudio
  • arts
  • esound
  • NAS
  • disk (write sound samples to a file)
  • dummy (null audio device)

I’m wondering if we should reorder that list for modern systems. My
thoughts are…

  • ALSA
  • PulseAudio
  • /dev/dsp with write()
  • /dev/dsp with mmap()
  • arts
  • esound
  • NAS
  • disk
  • dummy

My thinking is this:

  • ALSA is the best route directly to the hardware on modern systems. We
    take a risk, though, with drivers that can’t handle multiple streams,
    etc, though.
  • PulseAudio may be slower, so we want ALSA if we can get it, but if
    there’s a sound server running, that’s our favorite.
  • /dev/dsp is considered legacy in the kernel, and it’s almost always a
    wrapper for some other API at this point (with aoss, or OSS
    compatibility in the kernel, etc). Using it may “work” but work less
    well than other available methods.
  • arts and esound and NAS: whatever. These all fall into the “totally
    useless but better than nothing” category. The hope is that something
    else worked before we get here, and most systems will continue to fall
    through with no audio daemon running if they get here (so presumably if
    they want one, they’ll have arts OR esound running, but not both, so
    we’ll get the right one, as far as any of these are ever “right”).
  • disk and dummy aren’t ever used unless explicitly requested, so they
    sort of float down to the bottom by default.

I’m not sold that this is the correct order for ALSA, OSS, and
PulseAudio, though. Opinions, anyone?

–ryan.

2

I’m not sold that this is the correct order for ALSA, OSS, and
PulseAudio, though. Opinions, anyone?

Is there any reason to not try PulseAudio before ALSA? PulseAudio
is ALSA-based, so trying ALSA first on a PulseAudio system will always
succeed, going through PulseAudio’s ALSA wrapper. This wrapper isn’t
perfect (I’ve had some issues with it here at least), so it’s better
going directly through PulseAudio.

Similarly, trying ALSA before OSS is a good idea, since /dev/dsp on an
ALSA or PulseAudio system is just OSS emulation. The OSS emulation
opens the audio device exclusively if nothing else is playing sound
when started, has to be run through aoss or padsp to get mixed, and has
quality/buffering issues (scratching etc).

Which reminds me, I’ve set SDL_AUDIODRIVER=pulse on my box to make SDL
stuff “just work” here. This doesn’t work with SDL 1.3, as the driver
name changed to pulseaudio, and of course setting SDL_AUDIODRIVER to
pulseaudio doesn’t work on SDL 1.2. Would be nice if this was resolved
somehow.

  • Gerry
3

Den Tue, 28 Oct 2008 03:22:24 -0400
skrev “Ryan C. Gordon” :

  • PulseAudio may be slower, so we want ALSA if we can get it, but if
    there’s a sound server running, that’s our favorite.

Sorry, didn’t read the entire mail apparently =]. So, PulseAudio is
preferred over ALSA if the PulseAudio server is running, then? That
sounds fine.

  • Gerry
4

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

Hello,

Ryan C. Gordon wrote:

I’m wondering if we should reorder that list for modern systems. My
thoughts are…

  • ALSA
  • PulseAudio
  • /dev/dsp with write()
  • /dev/dsp with mmap()
  • arts
  • esound
  • NAS
  • disk
  • dummy

I like it. ALSA is pretty much the standard these days. AFAIK all the
big distros use it. If the user wants to change it he can easily set
the envvar or the packages could.

My thinking is this:

  • ALSA is the best route directly to the hardware on modern systems. We
    take a risk, though, with drivers that can’t handle multiple streams,
    etc, though.

Yes, but that’s also pretty rare on modern systems. I haven’t had
issues with dmix in ages (at least 3 years) and alsa is doing mixing on
all my hardware atm.

  • disk and dummy aren’t ever used unless explicitly requested, so they
    sort of float down to the bottom by default.

Disk before dummy seems a bit weird, but I’m assuming the user would
compile without sound instead of having it get to that point. Writing
to disk when not specifically asked (case of falling through) doesn’t
seem too sane.

I’m not sold that this is the correct order for ALSA, OSS, and
PulseAudio, though. Opinions, anyone?

Gerry does make a point on putting PulseAudio before ALSA if it has ALSA
as a backend (treating it as some higher level API). I’m not too
familiar with it so I don’t know how common it is. It’s the only doubt
I have.

If there are no inconveniences with putting PulseAudio before then
perhaps a 1 ms delay at SDL_Init( SDL_INIT_AUDIO ), then just go for it,
it’ll probably satisfy the most people.

So I’d probably go with.

  • PulseAudio
  • ALSA
  • /dev/dsp with write()
  • /dev/dsp with mmap()
  • arts
  • esound
  • NAS
  • dummy

(swapped PulseAudio/ALSA, removed disk)

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

iEYEARECAAYFAkkHbYQACgkQolm4VNX3QTyKQQCeO5QBwMKsIS9d9/zveAeVW8S+
vZsAoIsdsCLA/disM4d1ZFrYib6MjjI5
=1qA7
-----END PGP SIGNATURE-----

5

My thinking is this:

  • ALSA is the best route directly to the hardware on
    modern systems. We
    take a risk, though, with drivers that can’t
    handle multiple streams,
    etc, though.

Yes, but that’s also pretty rare on modern systems. I
haven’t had
issues with dmix in ages (at least 3 years) and alsa is
doing mixing on
all my hardware atm.

Actually, anything with a Realtek/Intel HDA chip (read almost all onboard sound at the moment so most laptop and a number of desktop boards) or the Creative X-Fi laptop card (which doesn’t actually have an X-Fi chip, for ?45 is ought to come gold plated) use software mixing which is most often done with PulseAudio these days.

But what do I care? I got a Terratec Auron :o)— On Tue, 10/28/08, Edgar Simo wrote:

From: Edgar Simo
Subject: Re: [SDL] Priority of audio devices…
To: “A list for developers using the SDL library. (includes SDL-announce)”
Date: Tuesday, October 28, 2008, 7:52 PM

6

Is there any reason to not try PulseAudio before ALSA? PulseAudio
is ALSA-based, so trying ALSA first on a PulseAudio system will always
succeed, going through PulseAudio’s ALSA wrapper. This wrapper isn’t
perfect (I’ve had some issues with it here at least), so it’s better
going directly through PulseAudio.

…except when you have real access to hardware in the ALSA path, in
which case it’s better to go directly through ALSA.

Can we detect the case where we’re using an ALSA wrapper for PulseAudio?
I’m not against trying ALSA first, but aborting if we see it’s a
PulseAudio wrapper and we built SDL with PulseAudio support.

Which reminds me, I’ve set SDL_AUDIODRIVER=pulse on my box to make SDL
stuff “just work” here. This doesn’t work with SDL 1.3, as the driver
name changed to pulseaudio, and of course setting SDL_AUDIODRIVER to
pulseaudio doesn’t work on SDL 1.2. Would be nice if this was resolved
somehow.

I’d rather we called it pulseaudio, but I can have it answer to both, I
think.

–ryan.

7

Disk before dummy seems a bit weird, but I’m assuming the user would
compile without sound instead of having it get to that point. Writing
to disk when not specifically asked (case of falling through) doesn’t
seem too sane.

You have to explicitly ask for these (and supply a filename for the disk
writer, too), or they won’t ever be used. Even with dummy,
SDL_OpenAudio() will fail before using it, unless explicitly requested.

–ryan.

8

Den Wed, 29 Oct 2008 12:13:35 -0400
skrev “Ryan C. Gordon” :

Is there any reason to not try PulseAudio before ALSA? PulseAudio
is ALSA-based, so trying ALSA first on a PulseAudio system will
always succeed, going through PulseAudio’s ALSA wrapper. This
wrapper isn’t perfect (I’ve had some issues with it here at least),
so it’s better going directly through PulseAudio.

…except when you have real access to hardware in the ALSA path, in
which case it’s better to go directly through ALSA.

That depends. Of course hardware mixing is better than software
mixing (if you can get it and not risk blocking everything else), but
PulseAudio does more than just software mixing. You also get individual
volume controls for everything, you can move streams around between
devices, etc. I think if someone has PulseAudio running, it’s fair to
assume that they want to actually use it.

Can we detect the case where we’re using an ALSA wrapper for
PulseAudio? I’m not against trying ALSA first, but aborting if we see
it’s a PulseAudio wrapper and we built SDL with PulseAudio support.

I don’t know, but it’s probably possible to detect if the PulseAudio
sound server is running.

  • Gerry