[hpsdr] buffer over/underflow (was Mercury sampling rate)

Roger Hayter roger at hayter.org
Mon Apr 14 13:33:28 PDT 2008


In message <217128.67612.qm at web34804.mail.mud.yahoo.com>, Chris Stratton 
<cs11102 at yahoo.com> writes
>***** High Performance Software Defined Radio Discussion List *****
>
>VE3NEA wrote:
>
>>So, when you have to throw away one block, because
>you
>>are in a condition of buffer overflow,
>>you throw away more than two elements of the incoming
>CW
>>signal. Not nice.
>
>Flawed assumption.  You do not have to throw away a
>whole block.  Keep all of your receive processing
>slaved to the clock of the data source.  Then, when
>sending output to the soundcard, do one of two things:
>
>1) If you are overflowing, tell the sound card you are
>giving it a receiver that is a sample or two shorter
>than the processing buffer actually was, discarding
>just that sample or two.
>
>2) If you are underflowing, tell the soundcard you are
>giving it a slightly larger buffer and repeate a few
>samples at the end.
>
>Presumably, for the transmit path you should do the
>opposite - finagle the buffer sizes when you get data
>from the soundcard, and keep the processing
>synchronous to the sample clock at the RF output.
>
>

Some sound cards can be synchronised to an external clock, including my 
(obsolete) STAudio DSP24, but I don't know how general this is.
-- 
Roger Hayter

 1208205208.0


More information about the Hpsdr mailing list