[hpsdr] Mercury sampling rate

Greg - ZL3IX zl3ix at inet.net.nz
Sat Apr 12 12:56:50 PDT 2008


I'm not sure what the final version of Mercury will do, but the 
development version I am running pushes the filtered and processed audio 
samples from the PC back down the USB, and outputs them from Mercury 
itself, using a PWM stream.  Thus the output sample rate (48 kHz) is an 
exact sub multiple of the input sample rate, and there is no glitch at 
all.  No sound card is used in the process.

73, Greg, ZL3IX

Alex, VE3NEA wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Alberto,
>
> The clock generator in the soundcards is crystal controlled and typically 
> has an accuracy of 10^-4 or better. Consider a program that inputs audio 
> data at a rate of 48 kHz in blocks of 1K samples, and suppose that the 
> output rate is lower than the input rate by 10^-4. When the input device 
> produces 10,000 blocks, the output device will consume only 9,999 blocks, so 
> one extra block is produced every 200 seconds. This results in one crackle 
> in the output audio every 3 minutes or so - which is totally acceptable and 
> is very difficult to detect by the ear in the background noise. Note that 
> the crackle occurs only in the data sent to the speakers but not in the data 
> used to compute the spectra, decode digital signals, etc.
>
> If the streaming buffer is properly designed, an extra block of data 
> produces exactly one click in the audio, but a poorly designed buffer may 
> result in a sequence of clicks that starts when the extra block is received 
> and lasts for seconds. This happens when the read and write pointers in the 
> buffer point at the same data block. A simple algorithm that avoids such 
> situation and ensures that no more than one click is caused by an extra data 
> block is implemented in my MmeAudioStream component, the source code is at 
> (http://www.dxatlas.com/dev).
>
> 73 Alex VE3NEA
>
>
>   


 1208030210.0


More information about the Hpsdr mailing list