Message-ID: <4FA6B3C9.7030900@freenet.de>
Date: Sun, 06 May 2012 19:24:25 +0200
From: wolf_dl4yhf <dl4yhf@freenet.de>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <FE434AB14D2442DA9517B6F7304CE6E3@AGB><FB72BFCD7B564064B0C93A0FD2DA9448@Extensa><4F97E9C2.9030000@iup.uni-heidelberg.de> <CAA8k23REzyvnLSkQGwzh4ckSFTeSFSPQkUMD2z-K9-YTGZfxQw@mail.gmail.com> <7B23411450514A5CB804E6D2C65A1876@JimPC>
In-Reply-To: <7B23411450514A5CB804E6D2C65A1876@JimPC>
Subject: Re: LF: Generating 8970 Hz carrier with Spectrum Lab ?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
X-AOL-SCOLL-URL_COUNT: 0  
x-aol-sid: 3039ac1d40834fa6b48e3738
X-AOL-IP: 195.171.43.25
X-AOL-SPF: domain : blacksheep.org SPF : none


Hello Jim,

Thanks for the detailed observation.
Under the hood (of SL) there is a 'worker thread' for the audio 
processing which currently uses a high priority - possibly too high, 
possibly higher than the thread used for the USB driver's own thread 
which actually communicates with the external USB device. The effect of 
'sporadically lost samples' seems to depend a lot on the USB device 
and/or its driver software. For example, I use the E-MU 0202 which 
doesn't give any phase glitches (I use it to monitor absolute phases of 
MSK signals on VLF over a long time). The E-MU a fast (ARM-) 
microcontroller built inside, which obviously buffers enough enough 
audio samples internally to avoid these drop-outs.
For very cheap USB audio devices (which presumable do not contain a 
microcontroller for audio buffering and processing) it may help to 
reduce the priority of SL's own 'worker thread' to avoid interrupting 
the USB I/O thread. This will be added in one of the next releases.

All the best,
    Wolf DL4YHF .


Am 06.05.2012 17:14, schrieb James Moritz:
> Dear Andy, LF Group,
>
> A bit late, but never mind...
>
>> Has anyone tried using an external USB soundcard with a separate
>> locked clock?   Most work from a 12MHz crystal which can be replaces
>> with a GPS locked source without too much effort. But I can't help
>> wondering if there will be subsequent USB synchronisation glitches
>> upsetting the input sampling.
>
>
> I can confirm that glitches do occur with USB sound cards. I have 
> found this to be a perennial problem trying to use such a sound card 
> with the laptops I have available. For 9kHz reception, the relatively 
> rapid temperature fluctuations inside the laptop, and resulting cyclic 
> drift of the internal soundcard sampling frequency interfere with the 
> operation of DL4YHF's ingenious sample rate correction facility in 
> SpecLab, making the internal sound card unusable for FFT resolution 
> below a few millihertz. I found my USB soundcard solved this 
> particular problem quite well, but introduced glitches that made 
> achieving FFT resolution in the uHz range impractical.
>
> Watching Speclab's sample rate correction "history" window, the USB 
> card sample rate typically starts off a few hundred ppm low (much 
> larger than the actual clock frequency error), but remaining stable to 
> within a few ppm, but then at unpredictable intervals abrupt jumps in 
> sample rate of a similar order of magnitude occur, with corresponding 
> "blips" on the spectrogram traces. The reported sample rate is always 
> lower than the nominal value, suggesting that some samples are being 
> periodically discarded somehow.
>
> The sound card uses a single-chip integrated audio codec and USB 
> transceiver, using a single 12MHz crystal. I can't really believe in 
> "USB slippage" in the hardware - surely losing some of the data would 
> either be handled quietly by the USB error checking, or result in 
> endless error messages. The same sound card seems to work in a 
> glitch-free way when plugged into my desktop machine, where the 
> reported sample rate error is in line with the error in the crystal 
> frequency.
>
> Cheers, Jim Moritz
> 73 de M0BMU
>
>
>