classic confined snap can't access audio devices

[Jake Kiesel]

When running inside of a snap with classic confinement I am unable to access audio devices. This is a bug because classically confined snaps are described by https://snapcraft.io/docs/snap-confinement as "Allows access to your system’s resources in much the same way traditional packages do."

See https://github.com/MonoGame/MonoGame/issues/7230 for further details.

[Zygmunt Krynicki (zyga)]

Hi

Could you please try something to see if this helps:

$ sudo snap set core experimental.classic-preserves-xdg-runtime-dir=true

And restart your application.

We are looking at making this standard, for now it's an experimental feature.

[Jake Kiesel (kieseljake)]

Unfortunately that didn't help, the output is exactly the same as before. Here's a minimal reproduction. To reproduce, follow the directions at https://github.com/dotnet/core/blob/05598dc0dcdc96b2fec338676890b182b40fc7c5/release-notes/5.0/preview/5.0.0-preview.6-install-instructions.md for installing either the snap package, or the debian packages.

Then cd into the directory and run `dotnet run`. If it worked, a screen displaying a simple blue background should appear. When it doesn't work, nothing comes up. Currently I can make this work with the debian packages, but not the snap packages.

[Jake Kiesel (kieseljake)]

"Then cd into the directory and run `dotnet run`."

I need to clarify, "the directory" here is AudioMinimalRepro which you get from unpacking the attached archive.

[Zygmunt Krynicki (zyga)]

Poking at the snap with strace I see:

277950 openat(AT_FDCWD, "/dev/dsp", O_WRONLY) = -1 ENOENT

Looking at mono game source code it seems that this is a fallback from OpenAL. I'm not an expert on dotnet or openal but it seems that what is going on is that we are hitting a fallback case that did not work on Linux for many years now (/dev/dsp is quite vintage).

I did not install the deb package as the installer does not support Ubuntu 20.10 development version yet and I didn't want to poke deeper into it.

In my opinion this is not a problem with snapd but rather with a particular snap (dotnet-sdk) and any additional dependencies it chooses to bundle or not.

Looking at monogame source code at https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Platform/Audio/OpenAL.cs we can see that it tries to dlopen libopenal.so.1 but I don't see this in the strace I collected.

Can you please help me understand how the sample source code you provided relates to monogame and if that's not mono game (is XNA mono game?) - where to look for the appropriate source code.

[Jake Kiesel (kieseljake)]

Sure, the source code I provided is a basic game template for the MonoGame framework. I just initialized a template, gave it a name, verified I could reproduce the problem with it, and uploaded it. libopenal.so is provided by MonoGame. It ends up in the compiled output in bin/Debug/net5.0/runtimes/linux-x64/native/libopenal.so.

Which I just noticed, libopenal.so != libopenal.so.1. So then at this point I believe the problem is that MonoGame isn't referencing the bundled library correctly. It happens to work outside of the snap because it's accessing my libopenal.so.1 file. I'll double check that's the problem this evening (in about 8 hours) but I'm pretty sure that's what's happening here.

[Jake Kiesel (kieseljake)]

Well wait, if that was the problem then we wouldn't even get the attempt to open /dev/dsp. That's an OpenAL fallback. Still the inconsistency there is interesting.

[Claudio Matsuoka (cmatsuoka)]

In my focal system the demo application loads the bundled libopenal.so (downloaded as a NuGet package), which then reads the system configuration file /etc/openal/alsoft.conf and tries PulseAudio and ALSA using the system libraries before falling back to OSS. It is unclear to me why the system libraries are failing, but I don't see ALSA accessing its configuration files or any of /dev/snd/* device nodes. Maybe it could be a bad interaction between the NuGet OpenAL and the system libraries?

[Claudio Matsuoka (cmatsuoka)]

Aha. This looks bad:

   2346312: /snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: error: version lookup error: version `GLIBC_2.29' not found (required by /usr/lib/x86_64-linux-gnu/libpulse.so.0) (fatal)

  2346312: /snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: error: version lookup error: version `GLIBC_2.29' not found (required by /usr/lib/x86_64-linux-gnu/libasound.so.2) (fatal)

(obtained running with LD_DEBUG=libs)

[Claudio Matsuoka (cmatsuoka)]

The reason it's failing seems to be the following: (remember that the application is on the main system whereas dotnet is a classic snap)

1 - Dotnet runs and loads the openal library from the application
2 - OpenAL dlopens the sound backend library installed on the main system
3 - The sound backend library links to libraries in core18 and fails because it needs newer symbols

Zygmunt, what's the clean way to solve this situation? We need the system sound back-end libraries to use the system libc, but it's the snapped dotnet interpreter that's opening the OpenAL library it downloads using NuGet.