ao_alsa: fix a log message

So apparently, this essentially happens when the kernel driver doesn't
implement write accesses in the channel map control. Which doesn't
necessarily mean that the channel map is unsupported, or that there is a
bug - it's just lazyness and a consequence of the terrible ALSA kernel
API for the channel mapping stuff.

In these cases, the channel count implicitly selects the channel map,
and snd_pcm_set_chmap() always fails with ENXIO.

I'm actually not sure what happens if dmix is on top of e.g. HDMI, which
actually lets you change the channel mapping.

I'm also not sure why commit d20e24e5d1614354e9c8195ed0b11fe089c489e4
(alsa-lib git repository) does not take care of this.

1 files changed, 5 insertions, 4 deletions

diff --git a/audio/out/ao_alsa.c b/audio/out/ao_alsa.c
index 1c4eaec139..fddc637e53 100644
--- a/audio/out/ao_alsa.c
+++ b/audio/out/ao_alsa.c
@@ -571,10 +571,11 @@ static int init_device(struct ao *ao, bool second_try)
 
         err = snd_pcm_set_chmap(p->alsa, alsa_chmap);
         if (err == -ENXIO) {
-            // I consider this an ALSA bug: the channel map was reported as
-            // supported, but we still can't set it. It happens virtually
-            // always with dmix, though.
-            MP_VERBOSE(ao, "Device does not support requested channel map (%s)\n",
+            // A device my not be able to set any channel map, even channel maps
+            // that were reported as supported. This is either because the ALSA
+            // device is broken (dmix), or because the driver has only 1
+            // channel map per channel count, and setting the map is not needed.
+            MP_VERBOSE(ao, "device returned ENXIO when setting channel map %s\n",
                        mp_chmap_to_str(&dev_chmap));
         } else {
             CHECK_ALSA_WARN("Channel map setup failed");