Dear Maintainer,

Currently, if an output device is not configured for the ALSA driver,
libao selects a default device based on the number of channels
requested.  For 2 channels it attempts to use the "front" device and if
this fails it falls back to "default".  Unfortunately, the "front"
device is not configured with dmix, so in its default configuration
users will be unable to use a libao application simultaneously with
other sound producing applications.

I'm not sure how current versions of dmix handle >2 channels, but for 2
channels I don't see a reason to prefer "front" over "default".  I think
it would provide a better out-of-box experience to users if "default"
was the default.

Thanks for considering,
Kevin


P.S.  Arch had a similar bug[1] and chose to change the default in the
config file.  I'd have changed it in the code, but that's just me.

1.  https://bugs.archlinux.org/task/33425

I think adding "dev=default" to /etc/libao.conf makes a lot of sense,
and should be done for Jessie.

The LibAO behavior, of selecting a different ALSA device depending on
the number of channels requested, is broken in light of ALSA's stock
configuration (where only the "default" device can be shared by multiple
clients). I see the choice here as being between

1. Leave libao.conf as-is. Any active LibAO application blocks all other
   ALSA clients (LibAO-based or otherwise).

2. Add "dev=default". Multi-channel (where "multi" > 2) LibAO
   applications are forced into using a stereo device.

Neither outcome is ideal, but #2 is a *lot* less broken than #1. Multi-
channel use cases are less common, too, and it's more reasonable to
expect configuration tweaking with those.

(The dev= line should probably also have a comment advising its removal
if default_driver= is changed; the comments on that ArchLinux bug
indicate that dev=default causes errors if one sets
default_driver=pulse.)

Some background:

The primary use of libao here is at Xiph is in various apps that have
to know what the hardware is doing, eg, Squishyball.  The problem with
plug devices like 'default' is that you could request 192kHz 24 bit
and ALSA will say 'sure!' and resample it down to 32kHz 8 bit because,
you know, ALSA.  And the app has no way of knowing that happened. And
in a listening test, that would be annoying at best, disastrous at
worst.

So, that's the primary reason libao tries to go to hardware devices
whenever possible.

Frankly, direct use of ALSA is deprecated on modern the modern desktop
except for specialized purposes-- like going as directly to hardware
as possible.  ALSA is not a modern, general purpose audio substystem
(not by itself).  Dmix does not change that, Dmix is not a substitute
for Pulse, and I can't fix the deep limitations inherent in trying to
use Dmix for things it just can't do.

Yes, this situation sucks-- but upstream I'm opting for the solution
that annoys me the least right now.  Better suggestions are always
welcome.  If there is really a way to fix this that doesn't shoot my
own primary use of libao, I'll definitely implement it.

...maybe libao should be running LDLIB and parsing/swapping in custom
.asoundrc files on the fly...?

Monty