Troubleshooting VSS

Camille Goudeseune


1. General techniques

In any audio system, hardware or software, the classic problem is it's not making any sound. Signal's coming in, but nothing's coming out. How do you tackle such a problem?

A general technique that has served me well in my battles with computers in the last ten years is Black-Box Debugging: learning as little as possible about the system, and always preferring simple and working to advanced and non-working. An implication this has for working with VSS is:

Notice the first error message that VSS prints out.

Later errors may be mere after-effects of the first one. VSS runs in real time, unlike a compiler or other batch-mode application. This means that once things go haywire, they tend to stay haywire. So you have to notice the point when things first went wrong. Maybe you won't figure out why things are going wrong, and you'll just find a workaround. But you first have to isolate the problem before you can deal with it.

2. Troubleshooting .aud files.

A miscellaneous list of things to watch out for.

3. Troubleshooting audio which uses sound files.

If you're using .aiff files to make sound, you're vulnerable to that ugly state-filled thing called the file system. Files and directories can move around; you may move your project around several times before it's finished. The basic maxim is:

Keep your .aud files and the file system in agreement.

Which leads to these questions:

4. Advanced techniques.

If you have a huge .aud file which prints out hundreds of messages as a result of "SetPrintCommands 1", you can pause and reduce that spewage to make it readable with strategic use of the commands described in this section of the reference manual.

You can increase the spewage with the command

at certain points in your .aud file. Or set it to 2 at the start of a message group, and reset it to 0 at the end.

You can also print out your own messages with the command ClientPrint on the client side, and the printfActor on the server side.

5. Arcana.

Little facts which only the True Geek should worry about.

Using "vss -input" under Irix
Ensure that in apanel, the default input device (as well as the default output device) has the same sample rate as VSS.

In Irix 6.3 and up, if apanel's default output device is "analog out", and the default input device is "digital in" showing a sample rate of 0 Hz (because there's no digital input signal), then "vss -input" will produce a nasty choppy sound as it tries to read samples which just aren't there to read. Change the default input device from digital to analog (and also set its sampling rate to VSS's).

Using "vss -input" under Linux
Most Linuxes ship with the OSS/Free sound drivers. These drivers use /dev/dsp for PCM audio I/O. They think that having /dev/dsp world-readable is a "security hole" in that remote users can listen to your microphone and hear things you might not want them to hear. If /dev/dsp's permissions are crw-rw--w-, either (1) chmod a+r /dev/dsp, (2) run vss as root, or (3) make vss setuid-root. (These last two are also security holes, of course.) The ALSA sound drivers seem to do (1) upon installation, as of April 1999.

Red Hat 6.0+ normally requires you to login to the console if you want to use /dev/dsp for input or output. To disable this, become root and change the line in /etc/security/console.perms from
<console> 0600 <sound> 0644 root.sys
to
<console> 0666 <sound> 0666 root.sys