Comment # 6 on bug 1037021 from Takashi Iwai

(In reply to Aaron Digulla from comment #5)
> Background: We're talking about "steam" here ... you know, the game client
> which tries to run Ubuntu on top openSUSE ...
> 
> That means: steam comes with a folder which contains many libraries which
> already exist on the host linux (openSUSE in this case) but slightly
> different versions.

Right, and that's the problem.  It tries to use the config file that doesn't
sync with that library version.

> There is a config option to say "run steam with the host libraries" but one
> of the last updates broke that, so steam doesn't start at all when I try
> that.
> 
> In our case, I have two versions of libasound2 which try to load the same
> (new) config file. It would be great if we could configure the config file
> for ALSA at runtime.

The config files can be stored in a different location and passed via the
environment variable $ALSA_CONFIG_PATH.  Check whether you have other config
tree similar as /usr/share/alsa/*, and set that path to the variable if found.
Or, copy /usr/share/alsa/* from the old libasound2.rpm to another directory.

> > This field was introduced only for Baytrail / Cherrytrail HDMI audio, and it should hit only that.
> 
> I'm using onboard Intel HD audio something. I could check the exact name if
> that matters (not at my computer ATM), but I'm 99% sure it's not that.
> 
> My guess is that an older version of libasound2 stumbles when it tries to
> parse these options even when they are not active (=no such hardware). Is
> that possible? Should ALSA ignore unknown options for uninstalled hardware?
> Or does it try to parse everything (fail early)?

Well, it's still strange and looks very buggy to me.  The code in question is
called only when the plugin is opened.  That is, the program actually tried to
open such a device.

But I have no idea, since it's the part in steam (or whatever).