Hi,
Since you're using mesa, please include what version of mesa you have installed.

A couple questions:
Is there any useful hints if you launch one of the games that have a problem after launching steam from a terminal?
Does the arch linux workaround when using mesa help? (found at https://wiki.archlinux.org/index.php/Steam#Steam_runtime_issues)
Can you confirm you have a working 32 bit opengl setup?

• tried Mesa 10.5.x and Mesa 10.6.0 with llvm 3.6.x
• 32 bit opengl works as far as I know because the 32bit binarys of the games work just fine IF I start them solo (not from steam) and also all NON-unity3D games just work fine...
• the steam_runtime workaround did not help (already tried that)
• there are always the same warnings and errors in terminal if I launch steam from terminal and then launch a game, for example:

Game update: AppID 268220 "Meltdown", ProcID 3003, IP 0.0.0.0:0 ERROR: ld.so: object '/home/tomtomme/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. /bin/sh: /home/tomtomme/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /bin/sh) /bin/sh: /home/tomtomme/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libtinfo.so.5: no version information available (required by /lib64/libreadline.so.6) ERROR: ld.so: object '/home/tomtomme/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. Found path: /home/tomtomme/1data/Steam/SteamApps/common/Meltdown/Meltdown.x86 Mono path[0] = '/home/tomtomme/1data/Steam/SteamApps/common/Meltdown/Meltdown_Data/Managed' Mono path[1] = '/home/tomtomme/1data/Steam/SteamApps/common/Meltdown/Meltdown_Data/Mono' Mono config path = '/home/tomtomme/1data/Steam/SteamApps/common/Meltdown/Meltdown_Data/Mono/etc' Game removed: AppID 268220 "Meltdown", ProcID 3003

here the full log.
https://gist.github.com/tomtomme/188865e68aadf6f35010

I tried googling the errors of course - what always lead back to the arch wiki, which did not help

exact specs from the intel system - all 3 machines run same software stack (openSUSE Tumbleweed, kernel 4.0...) except the graphics driver (radeonSI and intel)

`
Prozessor:
Hersteller: GenuineIntel
CPU-Familie: 0x6
CPU-Modell: 0x46
CPU-Stepping: 0x1
CPU-Typ: 0x0
Geschwindigkeit: 3400 MHz
8 logische Prozessoren
4 technische Prozessoren
HyperThreading: Unterstützt
FCMOV: Unterstützt
SSE2: Unterstützt
SSE3: Unterstützt
SSSE3: Unterstützt
SSE4a: Nicht unterstützt
SSE41: Unterstützt
SSE42: Unterstützt

Netzwerkinformationen:
Netzwerk-Geschwindigkeit:

Betriebssystem:
openSUSE 20150612 (Tumbleweed) (x86_64) (64 Bit)
Kernel-Name: Linux
Kernel-Version: 4.0.5-1-desktop
X-Server-Vendor: The X.Org Foundation
X-Server-Release: 11701000
X-Fenstermanager: KWin
Steam-Runtime-Version: steam-runtime-release_2015-01-06

Grafikkarte:
Treiber: Intel Open Source Technology Center Mesa DRI Intel(R) Haswell Mobile x86/MMX/SSE2
Treiberversion: 3.0 Mesa 10.5.7
OpenGL-Version: 3.0
Desktop-Farbtiefe: 24 Bit per Pixel
Monitor-Aktualisierungsrate: 60 Hz
Keine Anbieterkenn. entdeckt
Keine Gerätekenn. entdeckt
Anzahl der Monitore: 1
Keine Grafikkartenanzahl entdeckt
Prim. Anzeigeauflösung: 1920 x 1080
Desktopauflösung: 1920 x 1080
Prim. Anzeigegröße: 30,9 cm x 17,3 cm (35,4 cm diag.)
Kein prim. VRAM entdeckt

Soundkarte:
Audiogerät:

Speicher:
RAM: 7903 MB

Weitere Daten:
UI-Sprache: Deutsch (Deutsch)
SPRACHE: de_DE.UTF-8
Mikrofon: Not set
Verfügbarer Festplattenspeicher insgesamt: 175637 MB
Größter freier Festplattenspeicherblock: 6566 MB

Installierte Software:

Neueste Fehlerberichte:
Tue Feb 17 08:48:39 2015 GMT: file ''/tmp/dumps/assert_20150217094839_23.dmp'', upload yes: ''''
Tue Feb 17 08:49:13 2015 GMT: file ''/tmp/dumps/assert_20150217094913_26.dmp'', upload yes: ''''
Thu Feb 26 21:25:02 2015 GMT: file ''/tmp/dumps/crash_20150226222457_4.dmp'', upload yes: ''CrashID=bp-f49bb0cb-c53a-420c-b019-d07852150226''
Sun Mar 15 18:26:41 2015 GMT: file ''/tmp/dumps/assert_20150315192626_145.dmp'', upload yes: ''CrashID=bp-8fbd9fc7-d607-4762-b547-e256d2150315''
Fri Apr 3 10:13:02 2015 GMT: file ''/tmp/dumps/assert_20150403121301_29.dmp'', upload no: ''Failed sending data to the peer''
Sun Apr 5 19:50:43 2015 GMT: file ''/tmp/dumps/assert_20150405215043_30.dmp'', upload no: ''Failure when receiving data from the peer''
Tue Apr 14 14:53:59 2015 GMT: file ''/tmp/dumps/assert_20150414165351_21.dmp'', upload no: ''HTTP response code said error''
Tue Apr 14 15:16:12 2015 GMT: file ''/tmp/dumps/assert_20150414171603_18.dmp'', upload no: ''HTTP response code said error''
Fri Apr 17 14:05:26 2015 GMT: file ''/tmp/dumps/assert_20150417154313_1.dmp'', upload no: ''Failed sending data to the peer''
Wed May 13 14:53:24 2015 GMT: file ''/tmp/dumps/assert_20150513163853_1.dmp'', upload no: ''Couldn't resolve host name''
Wed May 13 15:32:39 2015 GMT: file ''/tmp/dumps/assert_20150513171536_43.dmp'', upload no: ''Failed sending data to the peer''
Mon Jun 15 08:53:45 2015 GMT: file ''/tmp/dumps/assert_20150615105334_39.dmp'', upload yes: ''CrashID=bp-a8a7e04e-57d1-4b30-992a-7a25e2150615''
Thu Jun 18 08:24:29 2015 GMT: file ''/tmp/dumps/assert_20150618102423_19.dmp'', upload no: ''HTTP response code said error''
`

I gave detailed logs and would like to provide more - please someone: reply!

I installed an OpenSUSE Tumbleweed VM and was able to reproduce the issue.
It appears to be a crash in the audio stack due to mismatches between the steam runtime and the host OS. (Related to https://github.com/ValveSoftware/steam-for-linux/issues/2924 ).
PulseAudio detection fails because of mismatches between the system and steam-runtime:

• pulseaudio vs. liborc
• libgcrypt vs. libgpg-error

Then FMOD selects ALSA, and the crash occurs in libasound2, apparently because of incompatibility between the library in steam-runtime and the host driver.

Either of the following worked around the issue for me:

• Moving the libgpg-error and liborc libraries (_both i386 and x86_64!_) out of steam-runtime (allows PulseAudio to be detected and used)
• Installing the alsa-devel and alsa-devel-32bit packages (seems to trigger the system libasound2 to be loaded)

THX!
I used the second method since the first would need repetition after a steam-update.
It worked!

I've submitted an update to the openSUSE Steam package ( https://build.opensuse.org/request/show/313151 ) . It will be available in one of the next TW updates

if alsa-devel fixes anything that means some program is linked incorrectly or dlopens the wrong library. Noone must open libasound.so at runtime. At runtime programs must use libasound.so.2. Please report that to the vendor of the program that tries to open libasound.so.

FMOD is in fact loading libasound.so.2 , but the presence of the alsa-devel packages changes how this gets resolved, apparently. I imagine one could achieve a similar effect by using LD_PRELOAD tomfoolery.

maybe it prefers libasound.so and then coincidentally loads the system libasound. I guess the real fix would be to remove other copies of libasound.so.2

As lnussel says, FMOD must dlopen libasound.so.2 rather than libasound.so, because there is no guarantee whatsoever that libasound.so is always version 2 (it could be v3 in future).

Second, as a workaround, steam could provide a libasound.so symlink in the same directory its own copy of libasound.so.2 is located.

What I do not understand yet - why did the games work (sound also) when I launched them without steam by clicking on the binary in dolphin? Is FMOD only used in steam? Isn´t the bug finaly something in the steam-runtime, which is not involved, when I run the game without steam?

When launching outside of steam, there was no mismatch with the system libraries and the steam libraries (because the steam libraries weren't in the loader path), so either:

• PulseAudio was correctly detected and used
• Alsa was able to correctly initialize and run

So...if I got this right...
will the fix-proposal of jengelh and Inussel be implemented in steam?
"FMOD must dlopen libasound.so.2 rather than libasound.so ... real fix would be to remove other copies of libasound.so.2"
Would be sad if the real fix is forgotten only because we have a workaround...

FMOD already opens libasound.so.2. The problem is that this resolves to the incompatible libasound2 in steam-runtime by default.

So, what would be the real fix?
And who has to implement it?

No, thanks