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.
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
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.
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.
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
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.
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.
Easy solution: install the “non-Snap” version of VSCode!
For Ubuntu, download the .deb here: https://code.visualstudio.com/Download
Install it and ALSA programs function correctly. No container in this version isolating your code from the audio hardware.