Nothern Utah WebSDR Logo - A skep with a Yagi Northern Utah WebSDR
Operating a WebSDR receiver at
384 or 768 kHz using the 16 bit signal path

The "traditional" types of receivers used with the PA3FWM WebSDR server are:
Covering the HF bands with a WebSDR:

For best performance, the best option - to date - has been to use the 16 bit audio (ALSA) interface - but this is limited to the rate of available audio devices - typically 192 kHz, meaning that any amateur band wider than this would require multiple receivers to provide complete coverage.  For example, complete coverage of 80 meters requires three such receivers while 40 and 20 meters require two - and coverage of 15 and 10 meters becomes increasingly problematic!  The fact that the WebSDR software has, at the time of this writing, support for only eight "bands" means that coverage of just the non-WARC bands from 160 through 10 meters would require at least two servers.

The 8-bit RTL_TCP path and its limitations:

To get around this many WebSDRs use the RTL_TCP path which can provide up to 2.048 MHz of coverage - but with this signal path supporting only eight bits, a problem of signal dynamics arises, particularly on HF.  There are several ways to mitigate - but not solve - this problem, including:
While the use of an AGC can help, it doesn't get around the problem of limited dynamic range of the 8-bit path:  When a strong signal is present within the passband, the gain must be reduced to prevent clipping of the A/D converter - but this can cause weaker signals to be submerged into the noise - which could be a combination of receiver noise and the noise caused by the action of the A/D converter itself when a signal cannot be represented by a sufficient number of bits.  Despite this limitation, an 8-bit signal path can work remarkably well under poor-to-moderately good HF band conditions, but when very strong signals coexist with with weak signals on the same band - as will more likely be the case as conditions on the higher HF bands improve with increased solar activity - the limitations will become increasingly apparent.

The 16 bit ALSA path:

The only other usable path available in the WebSDR software is via the audio interface.  Typically, ALSA is used as it is "closest" to the hardware (compared to the PulseAudio interface) and has less overhead and latency than any other of the inputs - including the RTL_TCP interface.  At first glance, it would seem that this path would be limited to 192 kHz due to the availability of hardware that operates up to this rate, but this isn't the case:  Several years ago - apparently prior to 2016 - the ALSA interface was patched to provide up to 768 kHz of throughput, possibly to accommodate specialty signal acquisition devices.  Not surprisingly, audio cards with 768 kHz interface - if they exist at all, are rare and expensive.

At this point, the question might be asked:  Does the WebSDR software itself support rates higher than 192 kHz, even if there are no devices that operate at that rate?

The answer is yes.  The PA3FWM WebSDR software can operate at 384 and 768 kHz with 16 bit data via the ALSA interface.


Getting >192 kHz data into the WebSDR:

While the ALSA core on modern Linux systems (specifically Ubnuntu 18.x and 20.x - I can't personally guarantee the same of any other Linux versions/distros) can operate above 192 kHz, many of the ancillary programs cannot do this and they must be patched.  Specifically, the loopback interface ("aloop") and the playback ("aplay") programs must be modified to permit these higher rates.  The signal path for feeding data into the WebSDR via ALSA from an SDRPlay RSP receiver, as an example, is as follows:

RSP API ->  Interface Program -> STDOUT -> aplay -> Loopback Interface -> WebSDR

A bit of explanation is warranted at this point:
A few comments:
Needed modifications:

The two elements above that need to be modified are "aplay" and the "loopback".  These are both parts of the ALSA sound system and as of the time of writing, both have built-in limits that prevent the use of rates higher than 192 kHz.  Fortunately, these are easily patched:  We have come up with an alternate version of each program/driver:
"How do I do this?

The instructions on how to patch and use "fplay" and "snd-fastloop" will be forthcoming soon.  We are still putting finishing touches on the "sdrplayalsa" program to assure stability and usability, but if you are interested in "early beta" testing, use the contact information below.

If you are interested in seen this code in action, please visit the Northern Utah WebSDR where the SDRPlay RSP1a is being used as the receiver on the following bands:

"Will this work with receivers other than the SDRPlay?"

While we do not have other receivers on hand to try, we do expect that any receiver from which you can get raw I/Q samples at one of the standard rates (e.g. 192, 384, 768 kHz) could be used with this method:  The means by which one would do this would depend on the specific hardware and its audio interface.  It's possible that the Soapy interface could be used, but this has not (yet) been investigated.

As noted above, the "sdrplayalsa" driver works not only with the RSP1a, but also the RSP2 and RSP2pro.  It has not been tested with the RSP1 or RSPduo.

More to follow.

Additional information:
 Back to the Northern Utah WebSDR landing page