No Sound in a Volumio VM
Having just installed Volumio in a Proxmox VM, I got to find out a lot about both Volumio and Proxmox. Both are Debian-based. Proxmox is (probably) server-oriented, and doesn't seem to provide a sound interface to its resident VMs (as I've come to expect of VirtualBox). Volumio falls down when installed on a system without a sound card: its failure to put up its default web page led to the discovery that A) it's Debian-based, B) the default account is user: "volumio", password: "volumio" AND that user can sudo anything (so secure!), C) the failing service (found with
systemctl list-units) was called "volumio" reasonably enough, D) the service file (/lib/systemd/system/volumio.service) simply called
/usr/local/bin/node /volumio/index.js. Unfortunately,
systemctl status volumio.service mostly told us "it's not working," but not why. So ... run the command by hand, and find out it's not running because there's no sound output device (I think it was looking for /proc/asound/ but I didn't note that down).
Creating a Sound Device in the VM
This led to a long voyage of discovery about the joys of sound in QEMU-based VMs. I was again assisted by Scott, without whom I wouldn't have made anything like this kind of progress. Our first attempt was to find the configuration for the VM - which in Proxmox is stored in /etc/pve/qemu-server/<NNN>.conf (where <NNN> is the number of the virtual machine that you'll see in the interface). Probably best to turn the VM off while editing this file. We added a line "args: -device AC97,addr=0x18". This resulted in us having a sound card that Volumio thought it could use, so it ran. But note the 0x18 address: that's just the address inside the VM (suggested, without explanation, by a web page we were reading), so if you run
lspci (this required a quick run of
apt-get update ; apt-get install pciutils to make it available) inside the VM you'll see (among other things) "00:18.0 Multimedia audio controller ..." But nothing about this says "hook up to the host machine sound." And as it turned out, there was no sound to connect TO ...
Testing Sound in Linux
Sound testing required
speaker-test: neither was installed. Under Debian, both are part of the alsa-utils package, so that was easily remedied with a quick
On the host machine we ran
**** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC280 Analog [ALC280 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0
(This is actually the output on my main laptop, but it's similar to the host machine: card 0, device 0 is analogue, the other is HDMI. The host had one analog, three HDMI.) So we want the sound going out the analogue device (the headphone jack, in this case used to drive a standard stereo).
speaker-test -c 2 -r 48000 -D hw:0,0 where the numbers in hw:0,0 are "<card>,<device>". This plays static through each of your two front speakers in alternation until you hit Ctrl-C. At which point we established that the host machine produces no sound at all. [UPDATE: a Sound Blaster USB device complained with the same command "Rate 48000Hz not available for playback: Invalid argument" but worked fine when I changed to
Scott had another interesting point to make: the host system is running on a generation six Intel i-series processor. Output from
cat /proc/cpuinfo looks like this:
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz stepping : 7 cpu MHz : 800.000 ... [etc.]
The machine listing above shows the processor is an i3-2310: the leading "2" in the numeric part indicates a generation two processor. The host machine I'm using is an i5-6NNN, thus a sixth generation machine. And this is a problem, as Scott has a fifth gen also Intel-based machine (sound is Intel too), and he hasn't managed to get sound out of that machine yet (and he's better at this stuff than I am). So I'm unlikely to have sound out of the headphone jack on that machine any time soon - although I might get it from the HDMI, if only that were useful to me.
[This happened a couple days later.] Add a USB sound device:
# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Pro [Sound Blaster X-Fi Go! Pro], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 0: ALC283 Analog [ALC283 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0
Unlike the previous run of
aplay -l I'm on the Proxmox host this time. Note we now have a USB Sound Blaster device installed. Scott has another point to make about USB sound devices: many USB devices are problematic under Linux because they need specific drivers. The problem generally DOES NOT apply with sound devices, because sound is part of the USB spec itself. It's ALWAYS supported. So even off-brand USB sound devices should work fine under Linux.
To get the Sound Blaster as the default device, I added a file /etc/modprobe.d/alsa-base.conf and added the following two lines to it:
options snd_usb_audio index=0 options snd_hda_intel index=-2
If the Archwiki link below is correct (and Archwiki is routinely one of the best sources for Linux system information around), this means I'm 1) setting the snd_usb_audio module as the first-loaded, and 2) by giving the snd_hda_intel module a value of "-2", I'm ensuring the Intel sound card will never be used as the primary. This is probably overkill, but works fine in practice. It should be noticed that because you're mucking about with modules ... this stuff doesn't work fully until after a reboot. And then, the previously added AC97 device in the Volumio VM suddenly "just works," so all is good.