Troubleshooting, known bugs and
How to find and report
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
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:
The preferred method to reports bugs is via the Spectrum Lab User's Group at Yahoo.
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.
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.
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:
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
"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.
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
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.
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
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
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
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