Troubleshooting, bugs and more

how to report bugs to the author
running the program in "debug"-mode, producing a logfile
a list of known bugs (and where to report new ones)
Spectrum Lab's main index

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

Read the manual or online-help system.
Don't miss the chapter "System Requirements and Installation".
Please Check For Updates before wasting your (and my) time searching for a bug which has possibly been fixed already.
Read the chapter known bugs and check if the problem is known, and if there is some kind of work-around.
Try to install the program on an other PC and try if the problem occurs on that PC, too
Reduce the sample rate, turn off all unused components
Close all other applications that run "in the background"
Run the program again, this time in debug mode, and check the logfile after a debug-run
If the bug causes a program- or even a system crash, please read this (and check the error log).
Check the User's Group (see link below); if the problem is windows- or hardware-related other users may have posted a workaround.
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 or similar hardware 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.
Don't forget to attach the debug run-log (debug_run_log.txt) to your message.

The preferred method to reports bugs is via the Spectrum Lab User's Group at Yahoo.
You may find similar bug reports there, and possible find a solution if the problem is related to a certain version of windows, or a certain hardware. If you are not using the latest version of Spectrum Lab, the author will most likely not be able to help.

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 folder (i.e. the directory where SpecLab.exe has been installed). Each line in that file is marked with the time-of-day, and a rather cryptic description of what has happened, or what went wrong (if the program had the chance to detect that 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 windows command prompt. If you don't know how to run a program from a command line under windows: A nice how-to used to be here.
Alternatively, the installer should have added an item in the windows 'Start' menu under 'All Programs'..'Spectrum Lab'..'Run Spectrum Lab in debug mode'.
This item launches a batch file, which in turn launches Spectrum Lab with the '/debug' switch as explained above. After SL terminates, the batch file shows the contents of the debug log in an extra console window.
After running Spectrum Lab with the 'debug' switch, the first few lines in the (debug-) logfile may look like this:

19:38:45.9 Logfile created, date 2012-10-15
19:38:45.9 checking instance...
19:38:45.9 Executable: c:\cbproj\SpecLab\SpecLab.exe
19:38:45.9 Compiled  : Oct 15 2012
19:38:45.9 Data Files: c:\cbproj\SpecLab
19:38:45.9 init application...
19:38:45.9 creating main form...
19:38:46.0 Constructing main form
  ... (many lines removed here) ... 
19:38:49.7 Sound devices started
19:38:49.7 Back from InitAudioDevices .
19:38:51.1 Launching Sound Thread
19:38:51.1 Clearing digimode chunks
19:38:51.1 Clearing audio chunks
19:38:51.1 Entering audio thread loop
19:38:51.1 First call of RunProcessingChain() ..
19:38:51.1 Back from RunProcessingChain()

If all went well, after quitting Spectrum Lab in 'debug' mode, the last lines in the logfile should look similar to this (there may be more, of course):

19:38:55.7 Beginning to close ....
  ... (many lines removed here) ... 
19:38:59.4 Deleting SPECTRUM objects
19:38:59.4 Deleting other buffers
19:38:59.4 FormClose done
19:38:59.4 Ok, all 85 dynamic memory blocks were freed.
19:38:59.4 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 the entire logfile (debug_run_log.txt) via email, or (preferred) to the Spectrum Lab User's Group mentioned in the next chapter.

Known Bugs (and "minor problems")

Note: The following list is quite outdated. As of 2012, an up-to-date list of bug reports, and possible fixes, was at the Spectrum Lab User's Group at Yahoo.

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 .

BUG04 (2011-08-09)

Program seemed to crash while trying to enumerate the available ASIO drivers. The last entry in the debug run log (/debug command line switch) was
"initialising ASIO wrapper" before an exception (access violation) occurred.
Possible workaround: Launch the program with the command line switch /noasio.
With the command SpecLab.exe /noasio the program will not try to load any ASIO driver, and not even query the driver's properties (it will only use standard multimedia drivers).

top of page