ALSA and 32bit game

[Anonymous]

Original thread was here, but after some more days of testings and some headaches, I think I was finally able to kind of sort the issue, at least to a point. In the process I found that issue was a *different* thing than originally believed, so I got different doubts. But since I can no longer edit the whole thread (the title there is now already misleading), I’m trying making a new, similar but updated thread, starting over again if I may.

There’s this game called Limbo by Playdead, which is 32bit and finally got native Linux port in 2014.
Pity they never made it both 32 and 64bit…

First the background.

I use Antix 19.4 x64, so I was installing all required i386 packages. Finally, when “ldd” command displayed no more “not found” libraries and running the binary gave no errors (missing libraries as well), got game running, but with no sound.

I noticed an error in console:
ALSA lib dlmisc.c:287:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_equal.so ((null): /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_equal.so: cannot open shared object file: No such file or directory)
This error is seemingly generated by alsa-lib itself, i.e., libasound.so.2 (package libasound2:i386), because only after installing it error appeared.

So I was missing another i386 library. Package containing such library is libasound2-plugin-equal:i386, but when trying to install it I got an error.
Long story short, package libasound2-plugin-equal has package caps as dependency; both are already installed by default in x64. Problem is, caps package has this long unresolved ancient bug, which effectively prevents multiarch installations. I tested it, and yes, effectively both versions install in the *exact same* “neutral” location /usr/lib/ladspa/caps.so, when they should be installed whether in /usr/lib/x86_64-linux-gnu or i386-linux-gnu respectively.

This particular issue has been even addressed here in the forums before some few times, by the way:
https://www.antixforum.com/forums/topic/gamers-steam/page/2/
https://www.antixforum.com/forums/topic/wine-staging/
https://www.antixforum.com/forums/topic/no-sound-in-zsnes/

Just for the record, replacing both packages to i386 versions makes the game finally work, but totally breaks system-wide sound, which is actually expected.

End of background.

So I tried other approaches.

Copied all needed individual i386 libraries beforehand to game’s directory, and tried running the binary with LD_LIBRARY_PATH=/path/to/directory preceding. Still the same alsaequal error mentioned above, and still no sound. All needed i386 libraries, including caps.so and libasound_module_pcm_equal.so, were present in game’s directory; yet libasound.so.2 refused to read it if not forcibly present in /usr/lib/i386-linux-gnu/alsa-lib/ directory…
Tried using “patchelf” command (also “chrpath”) to list binary’s current rpath; displayed “$ORIGIN”, which IIRC means binary looks for its needed stuff *right in the same location* binary itself currently is. So this is not actually the problem? Would make sense, since it’s certainly reading the previously copied libasound.so.2 library there…

Tried manually downloading and compiling from source libasound.so.2, for i386 of course. Still same result.

Did more internet searches… in another forum saw that someone with a “similar problem” just deleted/renamed /etc/asound.conf… What else to loose?
Surprise: it finally worked.

This made game sound finally work, while not breaking system-wide sound. Though I did notice that overall volume, both in game and rest of system, was slightly decreased.
Also I noticed a message in console repeated a couple of times while game running:
ALSA lib pcm.c:8424:(snd_pcm_recover) underrun occurred

After all this, I got different doubts; wondering if someone could help by any chance…

Why did renaming /etc/asound.conf make it work? What’s the explanation?
Why did overall volume went slightly down without /etc/asound.conf?
Can the “underrun occurred” errors be fully harmful?

Thanks very much beforehand.

[Member ModdIt]

Helpful

Up

1

::

hi ctcx,
maybe you can get some insights here, https://alsa.opensrc.org/Dmix

You may be better off to ask the alsa experts rather than this forum.
The underrun is well known, if sound is not distorting badly you can safely ignore it.
It neans the computer is not able to keep the sound buffer filled fast enough.

I did notice that overall volume, both in game and rest of system, was slightly decreased.

You can probably restore overall levels in the mixer, Pre amp default is set to a very safe standard level,
i.e. low.

[Anonymous]

Helpful

Up

0

::

After long searches, I think I finally understood the situation a bit better.

Seemingly, in the past, default volume ranges were often “a bit too low” most often in laptops. So an option was to configure a “Pre-Amp” device in ALSA configuration (either in /etc/asound.conf, or ~/.asoundrc for one user), which used a package called “alsaequal” (libasound2-plugin-equal on Debian). This “Pre-Amp” allowed slightly higher volume ranges while still being safe.
Also, this device is the one creating ~/.alsaequal.bin file when running any app playing audio; if ALSA is not configured with this device, the file is not created.

Why do I talk in past tense? Because it is seemingly no longer used, since a while ago already.
Seemingly latest Debian release doesn’t ship with it included by default, though still available of course. Same case with other distros.
Hell, original dev’s website doesn’t even exist anymore; it’s said he/she most likely quit.

AntiX comes with it pre-configured. Trying 32bit game would of course ask for 32bit alsaequal as well. Alas, the multiarch bug… But by deleting/renaming /etc/asound.conf ALSA no longer uses alsaequal Pre-Amp device, no longer tries to find those libraries, and uses whatever defaults it has.

With seemingly no more missing libraries, game finally worked.

The issue was that manually putting alsaequal libraries in game’s directory didn’t work at all; seemingly ALSA looks for them exclusively in system’s default path. I tried asking if this behavior could be changed, but got no answer, probably because of the same fact that alsaequal is “deprecated”…

Now, I’d like to ask, just out of curiosity, what would be your posture regarding this seemingly obsolete plugin?
I mean, I guess there’s a reason to still include it installed in AntiX?

Thanks.

[Author]

Posts