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.
- If you get an error trying to LoadDSO a DSO,
ensure that VSS can find the DSO in question.
For releases of VSS prior to Nov. 5/99,
VSS will in general not work if it's in a directory in your
path somewhere and you haven't told VSS where to look for its DSOs.
Two ways to do this, assuming the DSO (and VSS) are in the directory /foo/bar:
Simply typing /foo/bar/vss (directly, or implicitly from a csh alias, or typing vss when /foo/bar is in your path)
without also setting the environment variable SOUNDSERVER_DSO to /foo/bar will not work.
The section on LoadDSO in the reference manual gives all the details.
- % setenv SOUNDSERVER_DSO /foo/bar; /foo/bar/vss
- % cd /foo/bar; ./vss
Releases after Nov. 5/99 can have VSS run from any directory and
still be able to find its DSOs.
- If you get an error trying to Create an actor,
did you first LoadDSO the DSO containg that actor?
- If a sound isn't changing and you think it should be,
ensure that you're trying to change the sound, not the
actor which created it.
This is wrong:
a = Create MyActor;
s = BeginSound a ...;
... SetAmp a ...;
This is right:
a = Create MyActor;
s = BeginSound a ...;
... SetAmp s ...;
It's a good idea to use some kind of naming convention
to distinguish actors from sounds (like aFoo and sFoo).
- Are you missing a semicolon at the end of a line?
(VSS is pretty good at guessing this situation, and will warn you.)
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:
- Do your "SetDirectory" commands point to the right directory?
- Are the .aiff files really in that directory?
- Can VSS (the server, not the client) find that directory?
Is that directory on a disk accessible from the machine running VSS?
- Are the .aiff files really .aiff format? (What does "sfinfo" report?)
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
this section of the reference manual.
- SetPrintCommands 0
- SetPrintCommands 1
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
on the client side, and the
on the server side.
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
<console> 0600 <sound> 0644 root.sys
<console> 0666 <sound> 0666 root.sys