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
|
