Tips and tricks
Audio support in VmWare ( By uriel Last mod: Aug 6 03:35 )
Continuing with the audio theme, this week I will explain the arcane black magic rituals (ie., undocumented or at least badly documented) required to get audio working on Plan 9 when running inside a VmWare instance.
Maybe I will write instructions on how to install Plan 9 from scratch under VmWare, but the process should not be too painful now that a patch to disable vga acceleration by default when under VmWare has been accepted in the standard distribution.
After you have Plan 9 up and running one needs to enable SB16 emulation in VmWare, this is not possible with the GUI configuration tools, so after sacrificing a goat to the God of Mysterious Ways and adding the default audio device using the GUI interface you should find the .vmx configuration file for your Plan 9 VmWare image, open it in a text editor and make sure it contains the following lines:
sound.virtualDev = "sb16"
sound.baseAddr = "0x220"
sound.dma16 = "5"
sound.irq = "7"
sound.autodetect = "FALSE"
This should work most remotely recent VmWare version. Now all we need to do is configure Plan 9 to use the virtual SB16, and this part is quite trivial despite the IMHO rather obtuse device configuration line because Plan 9 actually has proper documentation you can read and find with lookman(1) ;)
term% 9fat:
term% grep audio0 /n/9fat/plan9.ini
audio0=type=sb16 port=0x220 irq=7 dma=5
Make sure that the audio0 line is part of the configuration for whatever kernel you are going to use and reboot (if you are only booting one kernel just make sure that line is somewhere in your plan9.ini).
Now reboot and all that is left is to mount your new audio device with:
term% bind -a '#A' /dev/
Of course you will want to put that in your $home/lib/profile or riostart script so it is up and working in all your namespaces.
Thanks to Federico G. Benavento (aka fgb) for initially pointing out to me that this was possible and thanks to that after some archaeological research on unofficial VmWare docs I got it to work.
Redirecting audio output over a network with Inferno ( By uriel Last mod: Jul 11 20:56 )
We are inaugurating a new NineTimes section for small tips and tricks.
The first one explains how to export all audio output from a Linux box over the network using Inferno to any other system that can run Inferno (or to native Plan 9) without having to mess around with pulseaudio or any other such beast.
The difficult bit is figuring out how to get ALSA to output all audio to a fifo, you will need to have this in your /etc/asound.conf (note that many lunix systems don't include that file by default so you might need to create it):
pcm.!default {
type file # File PCM
slave.pcm "hw:0,0" # This should match the playback device at /proc/asound/devices
file /tmp/audio # Output filename
format raw # File format ("raw" or "wav")
perm 0666 # Output file permission (octal, def. 0600)
}
The slave.pcm is the most mysterious and magic part, hw:0,0 should work in most cases, but if for example you have an entry like: 48: [ 1- 0]: digital audio playback you should use "hw:1,0".
Once you have alsa setup properly do: mkfifo /tmp/audio; chmod 666 /tmp/audio
And you are done messing with Linux and can move on to the real easy part, start Inferno's emu: emu ; bind '#U*/' /n/local/ ; listen -A tcp!YOUR.LINUX_BOX.IP.ADDRESS!9999 {export /n/local/tmp/}
Now go to your windows or OS X box start Inferno there and run (tried this in acme-sac, which has a reasonable default setup, if you are using inferno-os you might need to mount your '#A' device to /dev): ; echo rate 44100 > /dev/audioctl ; mount -A tcp!YOUR.LINUX_BOX.IP.ADDRESS!9999 /n/lunix ; while {sleep 1} { cat /n/lunix/audio > /dev/audio }
And you are done, after this all audio you play on your linux box should be heard on your other box. How to listen from Plan 9, do proper auth, and how to reverse the setup so you export the audio device rather than the fifo are left as exercises for the reader.
Thanks to hiro for that inspired this trick (he was doing the same but with only the output of mpd), and thanks to the folks in the #alsa irc channel that helped me decipher the incomprehensible ALSA docs.