Bug 1037021

Things get worse when /sbin is on the path. My feeling is that one of the last updates broke alsa and a few more libraries which steam uses.

These bugs might be related:

https://bugzilla.opensuse.org/show_bug.cgi?id=1021095
https://bugzilla.opensuse.org/show_bug.cgi?id=1025841

Things that work:

LD_PRELOAD="/usr/lib/libasound.so.2:/usr/lib64/libasound.so.2" /usr/bin/steam

Things that don't work:

- STEAM_RUNTIME=0 /usr/bin/steam

Complains about a bunch of missing libraries (libXtst, ICE and IM). When I install them, it can't connect to the Internet anymore and crashes shortly afterwards.

- steamtricks

No positive effect that I can notice.

- Add /sbin to the path or putting ldconfig in the path by linking it to ~/bin

Crashes when trying to load fonts, alsa error is gone from the terminal but it still doesn't work.

The field was introduced to the recent alsa-lib and this was included in the update of libasound2.  It implies that you're using the alsa-lib configuration for the updated one applying incorrectly to the old library.

That is, it's a wrong usage that existed from the very beginning, not the regression.  Please fix your setup and script.

BTW, which hardware are you using?  This field was introduced only for Baytrail / Cherrytrail HDMI audio, and it should hit only that.

... or is it a 32bit app and you forget to update libasound2-32bit.rpm?

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.

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.

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

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

Okay, I'm now on my computer. AlsaMixer reports I'm using HDA Intel PCH / Realtek ALC892.

I have both 64 and 32bit package installed and both have the same version:

Name        : libasound2
Version     : 1.1.3
Release     : 8.6.1

I have only a single alsa.conf on my harddisks. grep says there are three places where direct_memory_access is used in the whole tree:

/usr/share/alsa/cards/HdmiLpeAudio.conf:HdmiLpeAudio.dmix.direct_memory_access false
/usr/share/alsa/pcm/dmix.conf:	direct_memory_access {
/usr/share/alsa/pcm/dmix.conf:				".dmix.direct_memory_access"

The second hit is inside a structure which starts with "pcm.!dmix {" right at the start of dmix.conf.

> ALSA_CONFIG_PATH

I found an old copy in a snapper snapshot which I tried to copy out of the snapshot and pass to steam using the ALSA_CONFIG_PATH.

Unfortunately, this gave me a new error and no sound:

ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
[0502/220815.365432:WARNING:alsa_util.cc(24)] PcmOpen: default,no such file or directory

I found this file inside of steam

libasound2_1.1.0-0ubuntu1+steamos1+srt2_amd64

which suggests steam comes with libasound2 1.1.0. I also found a changelog.gz and changelog.Debian.gz which says the same.

Regarding alsa config: How distribution specific is the config? Would it make sense to keep a copy inside of steam to match the libasound2 in there? Or would it make more sense to force steam to always use the installed libasound2?

Thanks for testing, and sorry, this was the wrong information.  There is no override of the config directory by the environment variable.  $ALSA_CONFIG_PATH specifies the main config file, but it can't change the default config path that other files may include.

After thinking of this problem and the current situation again, I concluded that removing the new stuff would be better so that the old alsa-lib can still work somehow.  Although the usage of the old alsa-lib with the new config is clearly invalid, your use case implies that it's widely deployed, and we should avoid breakage.

I'll fix up the upstream code and backport.

The fixed package is ready at
  http://download.opensuse.org/repositories/home:/tiwai:/branches:/openSUSE:/Leap:/42.2:/Update/openSUSE_Leap_42.2_Update/

Could you give it a try?

 "Takashi Iwai 2017-05-03 08:15:19 UTC

The fixed package is ready at
  http://download.opensuse.org/repositories/home:/tiwai:/branches:/openSUSE:/Leap:/42.2:/Update/openSUSE_Leap_42.2_Update/

Could you give it a try?"


Thank you, I was affected by the same problem, used your new package and I can confirm that it works without problems.

Of course I am going to keep the fixed packages until the fix is committed to the regular repos. How to keep track? (I don't know if you'll announce it here).

I was desperate yesterday with this, you're a hero. :)

This is an autogenerated message for OBS integration:
This bug (1037021) was mentioned in
https://build.opensuse.org/request/show/492960 42.2 / alsa

(In reply to Marguerite De la Torriente from comment #10)
> Of course I am going to keep the fixed packages until the fix is committed
> to the regular repos. How to keep track? (I don't know if you'll announce it
> here).

You can add the lock via zypper, but I guess you leave it as is unless you have another external repo containing libasound2 package.

In anyway, I submitted the update to 42.2:Update, too.  The fix for TW was already submitted.

Now let's close the bug.  Thanks for reporting and testing.

Processed for maintenance. Test packages will appear first in:
http://download.opensuse.org/repositories/openSUSE:/Maintenance:/6660/openSUSE_Leap_42.2_Update/
http://download.opensuse.org/update/leap/42.2-test/

openSUSE-RU-2017:1255-1: An update that has one recommended fix can now be installed.

Category: recommended (moderate)
Bug References: 1037021
CVE References: 
Sources used:
openSUSE Leap 42.2 (src):    alsa-1.1.3-8.9.1

Thanks for the fix, it also works for me.