开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Airspy
  2. Topics

Fractional Resampling Rate

 

Greetings,?
?
Is there a way to lock the fractional resampling rate in SDR#??
?
I can within uno and it makes a big difference in keeping the horizontal sync line from shifting when decoding WEFAX stations.?
?
I would like to use SDR# for decoding WEFAX.?
?
Thank you,?
George, NJ3H?
Redmond, Oregon USA?
 

On Sun, Mar 23, 2025 at 06:56 AM, George Stein - NJ3H wrote:
Greetings,?
?
Is there a way to lock the fractional resampling rate in SDR#??
?
I can within uno and it makes a big difference in keeping the horizontal sync line from shifting when decoding WEFAX stations.?
?
I would like to use SDR# for decoding WEFAX.?
?
Thank you,?
George, NJ3H?
Redmond, Oregon USA?
?
Imagine you build a state of the art DSP with 130+ dBc SFDR only to finally ruin it with a wobbly resampler. That's what tracking the sample rate differences does. It speeds up/slows down the playback, resulting in a wobbly signal in the end. Most digital signals are ruined with such added distortion. If your other hardware is already worse than this distortion, it could be perfectly acceptable. For Airspy, it's definitely not the case.
The Audio DAW industry encountered these problems ages ago and they figured the only viable fix would be to have the ADC and DAC in the same box - which gave birth to the audio interfaces you see now in the market. If you are familiar with DAW software, you will notice that the "drift compensation" is not recommended. In some high end software, it's grayed out until you accept that your work may be corrupted and it's all your fault.?
Now let's step back a bit. Why do we have a problem between two software instances (SDR# and WEFAX decoder) with no hardware involved? Aren't they supposed to synchronize automatically? Most Virtual Audio Cables impose a clock derived from the computer itself, which will ruin your streaming however you do.?
So, how to handle this with SDRs? Assuming an Airspy hardware with Airspy drivers.
  1. Let the SDR hardware handle the overruns/underruns. At high sample rate and super small buffer sizes (a few samples in the USB packets) the extra/missing buffers become unnoticeable after decimation. The higher the sample rate and the decimation, the better. Nothing to do here, it's already implemented.
  2. The playback of recorded IQ files is already synchronized with the audio interface. No problem to solve in the first place. If you record your signal, then decode it, you eliminate one clock out of the equation.
  3. Rely on the SDR's sample rate for demodulating digital signals, not your virtual cable's clock - thus eliminating one clock out of the equation. This can be implemented with two different means:
    1. Have the demodulator implemented as a plugin. The plugin system sets the correct sample rate for it, and there are no conflicts, since there is no output audio interface.
    2. Use a synchronous virual cable, like . This ensures both the sender and the receiver are synchronized. You may need to use a PortAudio.dll build that supports ASIO, but that's a detail. The old SDR# packages have ASIO enabled in PortAudio.dll.?
Additionally, you can force SDR# to synchronize the input and output streams like a DAW by forcing two config keys (in the 1922 beta) to true: <add key="core.optimizeStreamingForLatency" value="true" /> and <add key="core.letHardwareHandleOverUnderRuns" value="true" />. Then increase the audio buffer just enough (like 100ms) to compensate for the overhead.?
?
As this is a recurrent question, this post is detailed enough to be used? as a reference for later. There is more info than the usual "What button solves my problem." Take some time to experiment.??
?

1 - 2 of 2