Well, I have tried two more sound cards, including the internal one and they all do this. I have been playing with every setting I can find and nothing seems to fix the problem. I found that increasing the "audio chunk size" by a small amount and then clicking 'apply", the problem would go away for about a minute and the start again with a dropout about every 12 seconds.
It also seems that the problem takes a minute or two to develop after starting SpectrumLab. It is like a buffer is filling up and then the problems start.
--- In SpectrumLabUsers@yahoogroups.com, wolf_dl4yhf wrote:
> Hello Tony,
> Thanks for the image. The problem may be related to the time source
> itself, which was one of the changes between V2.75 and V2.78. The older
> versions retrieved data from a buffer (to feed the FFTs for the
> spectrogram) based on the number of samples, while the newer versions
> use the precise timestamps. If there's a gap in the timestamps, there's
> a gap in the spectrogram. This may be caused by the configurable 'time
> source', even though someone mentioned having tested all options but
> none of them cured it.
> Anyway, if the soundcard's sampling rate is too far off, the timestamps
> (when based on the sampling clock) may be off too far after the program
> was running for some time. If the difference between the sample-based
> time, and the PC's system time exceeds a certain value the timing resets
> automatically (usually with an entry in the error log). I will try
> myself by deliberately entering a 'very wrong' sampling rate in the SR
> calibration table, and see what happens.
> Wolf .
> Am 07.02.2013 02:42, schrieb mux_folder2001:
> > Referring to file in folder "TonyC" called dropout.jpg:
> > I have uploaded a side by side of 2.78 and 2.75 listening to the same
> > NDB. 2.78 shows a dropout at about the 44 Second tick mark while 2.75
> > does not. You can also see the timestamps pushed together. The beacon
> > is TAD which isn't displaying too well because of the contrast being
> > set too high.
> > Tony