VSCode, Ubuntu Snaps and ALSA Sound Development

Here at McLaren Labs we like to try all sorts of tools and development environments to see how they work together. We’ve been using vscode (https://code.visualstudio.com/) on and off for about a year, but only recently decided to try using it for a more complete edit/debug/run cycle for an Objective-C Synthesizer project. We ran into an unexpected interaction between the Snap environment of vscode and the ALSA (Advanced Linux Sound Architecture) PCM interface.

The Symptoms

What we discovered was that when running a program that attempted to access an ALSA sound device was that the program malfunctioned. It worked correctly in a “normal” terminal, however.

We reproduced the behavior using the default aplay command that is available in alsa-utils. See the screenshot below for what should appear in a terminal when it is run, playing an Ubuntu standard sound called “Front-Left”. Unless otherwise specified, this command opens the “default” sound device.

If your Ubuntu sound system is set up correctly, you will hear a woman saying “Front Left” … and it will come out of your front-left speaker.

However, when we executed this command from within vscode – whether from a terminal or a task command – the command failed. See the screenshot below.

In the terminal at the bottom you can see the error message

ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave

This is very strange behavior indeed. Why would the same command run successfully in a normal terminal, but not from within vscode?

Ubuntu and Snaps – Snapcraft

A “snap” is a way of packaging a program for Linux. A “snap” is a containerised software package that contains a binary and its dependencies. One goal of packaging programs as containers is to reduce undesired dependencies between different software applications. Another goal is to reduce the permissions that an application needs to just what the application actually needs to do. For example, a text editor may not need access to your camera, so it shouldn’t have access.

Unfortunately for us and our synthesizer development, the vscode snap was packaged without ALSA support. Or perhaps there is ALSA support, but it does not work correctly with Pulse (the sound server).

What we have discovered is that the ALSA configuration inside the Snap is different from what is outside the Snap. See these two files.

/usr/share/alsa/alsa.conf
/snap/code/50/usr/share/alsa/alsa.conf

The first file is what you see if you look at /usr/share/alsa/alsa.conf in a normal terminal window. The second file is what you see if you look at /usr/share/alsa/alsa.conf while within the terminal inside of vscode: the configuration of ALSA inside the container is different from the configuration outside the container.

See this screenshot for a e-diff of the two files.

We are not sure if it is the different configuration that is the root of a problem, or whether there is snap permission or interface that is missing.

A Detour

Here we take a slight detour from the main discussion and give a preview of what may be ahead. Visual Studio vscode has great support for Objective-C. When configured correctly, it can use the clangd language server (https://clangd.llvm.org/)for syntax checking of all of your Objective-C code as you type. Using clangd, vscode has a good understanding of your ObjC code and it can auto-complete, show comments inline and correctly follow includes and find symbols. It’s pretty great, and we’ll share how we set this all up in another article. It is almost like having XCode for Objective-C on Linux.

Conclusion

As of right now, we do not have a solution for opening the “default” sound device from within our vscode Snap. Instead, we can develop and debug code from within vscode but we have to run it outside in a normal terminal. There may be a way to configure vscode or its Snap but we haven’t found it yet.

If you have run into something similar, please share what you have discovered in a comment below. And if we find a solution to this problem, we will share it here.

All in all – we think that vscode is pretty amazing ( it has great Objective-C support) and would like to use it as part of our sound development workshop. So we will keep looking for a solution to this problem.