Troubleshooting, known bugs and more...

• how to report bugs to the author
• running the program in "debug"-mode, producing a logfile
• a list of known bugs
• Spectrum Lab's main index

If you encounter any problems with this program, follow these steps..

1. Read the manual or online-help system
2. Read the chapter "System Requirements and Installation" again.
3. Read the chapter known bugs and check if the problem is known, and if there is some kind of work-around.
4. Try to install the program on an other PC and try if the problem occurs on that PC, too
5. Reduce the sample rate, turn off all unused components
6. Close all other applications that run "in the background"
7. If the bug causes a program- or even a system crash, please read this (and check the error log)
8. If still no cure found, send me an error description via email including the following points:

• what kind of PC are you using (CPU-clock, RAM size, Windows-version)
• what kind of soundcard are you using
• what are the settings when the problem occurs (most important: sample rate)
  It's a good idea to attach your SETTINGS.INI or similar.
  

top of page

Running the program in "debug"-mode, producing a logfile for post-mortem analysis

In some tough cases (were the program seems to crash, or locks up), you can help to find the problem using a special debugging feature which is built into Spectrum Lab.

When started with the command line parameter /debug, the program will produce a textfile named "debug_run_log.txt" in the installation archive. Each line in that file is marked with the time-of-day, and a rather cryptic description of what has happened, what went wrong (if the program had the chance to detect this before "dying"). If you create a desktop icon for SpecLab, you can modify it (right-click the icon, then select "properties" (or "Eigenschaften" on a german PC). After the path and filename of the executable, append a single space character, and the /debug switch. The result should look like this:

C:\Spectrum\SpecLab.exe /debug

Then start the program by clicking on the modified icon, or entering the above line on the DOS command prompt.

After that, the first few lines in the (debug-) logfile may look like this:

20:24:17.1 checking instance...
20:24:17.1 init application...
20:24:17.1 creating main form...
20:24:17.1 Constructing main form
20:24:17.1 initialising ASIO wrapper
20:24:17.1 initialising SDR-14 / SDR-IQ control
20:24:17.1 creating CSound object
20:24:17.1 Parsing command line
20:24:17.1 main form constructed

If all went well, the last lines in the logfile should look similar to this (there may be more, of course):

20:28:05.8 Deleting SPECTRUM objects
20:28:05.8 Deleting other buffers
20:28:05.8 FormClose done
20:28:05.9 Reached last termination step; closing logfile.

If you find strange looking lines with one of the following messages in the logfile....

• "PANIC: Integrity check failed..."
• "PANIC: Someone destroyed an XYZ structure in memory"
• "SERIOUS BUG: ..."

... then please send me a copy of this logfile via email .

BUG01

• Input from Soundcard suddenly is extremely "noisy",
  Output from Soundcard suddenly is extremely "noisy" (hissing sound)
• Workaround: Turn the sound processing off and on again. Often the problem disappears this way.
  Note: Disappeared (without a trace :-) somewhere between Release V1.5 and V1.6 .

BUG02

• Spectrum Analyzer works ok if only the sound INPUT is active, but there seems to be somthing wrong if also the OUTPUT is active at the same time.
  Possible reasons:
  A- your mixer control program does not allow separate volume control for the "wave" input (ADC) and the "wave" output. Because programming the soundcard's "mixer" directly is too ugly, there is no cure for that right now.
  B- you have a nasty soundcard which uses slightly different sample rates for input (ADC) and output (DAC). Too bad- Spectrum Lab cannot cope with such soundcards.
• Workaround for B: Try a different sample rate, often 11025 is better than 8000 samples/second. Spectrum Lab can decimate the sample rate by software if required.

BUG03 (minor)

• When running the soundcard in full duplex mode (input and output running at the same time), there are "kinks" in the audio output. When only the ouput is active, it's ok.
  
• Possible reason and workaround: You may have one of the "strange" soundcards where the sampling rates of the input (Analog-to-digital converter) and the output (digital-to-analog converter) are *slightly* different. This causes an overrun of the input buffer, or an underrun of the output buffer. The problem can be bypassed as explained here .

top of page