Skip to content

Performance Notes

Jump to bottom
Dave Hayes edited this page Jun 2, 2026 · 1 revision

SolidSDR should work well on any reasonably modern hardware. When we're talking about performance, there are actually two different things we need to consider.

The Server

There are 3 main things that are going to affect solid-sdr-server performance:

  1. Network connection
  2. CPU encryption performance
  3. Client activity

Network connection

Obviously, the faster the better, but also the more stable the better. This is true no matter what you're using to interface with a FlexRadio. Throughput is a concern, so a 1Gbps connection is generally going to be better than a 100Mbps connection, but packet loss is also a factor. That's why wired connections will always be preferred over wireless. For the best performance, ensure you have the fastest, lowest loss connection between the radio and smart-sdr-server that you can manage.

That being said, SolidSDR should generally do a better job of handling connections to the server over WiFi or mobile networks that most other apps because we get the benefit of WebRTC. Still, the best experience will always be a wired connection.

CPU performance

Raw CPU performance is important, but solid-sdr-server relies on WebRTC, which in turn makes heavy use of AES encryption. Since AES encryption is so ubiquitous, most modern CPUs include hardware acceleration for AES encryption in the form of a specific aes instruction set. If your CPU lacks this instruction set, it will have a dramatic effect on server performance. Some high profile devices that are lacking this feature are the Raspberry Pi 3/4. You can find more information on the Raspberry Pi page.

If you'd like to check whether your CPU includes the AES or AES-NI instruction set, you can use an application like CPU-Z or HWiNFO on Windows, the lscpu command on Linux, or the sysctl -a command on macOS.

Client activity

The biggest consumer of performance in solid-sdr-server is large numbers of UDP packets. These are the most demanding things for server resources:

  1. DAX IQ streams
  2. DAX streams
  3. Panadapter data
  4. Waterfall data
  5. Remote Audio

If you're noticing the server is having trouble keeping up, there are a few things you can try.

  • Reduce DAX IQ rate, or disable entirely. DAX IQ is very expensive, and most Pi-style SBCs will struggle with it.
  • Don't enable DAX streams unless you need them.
    • Ideally, you only want to use DAX for digital modes (FreeDV, WSJT-X, etc)
    • While you can use DAX for phone modes, Remote Audio is much more lightweight and will generally be a better experience
  • Reduce Panadapter FPS (default is 25)
  • Increase Waterfall line duration (default is 80ms)
    • Note, this setting works in reverse of how the "rate" control in SmartSDR does! SmartSDR uses a 0-100 "rate" or speed value, while SolidSDR shows you the actual line duration in milliseconds.
  • Remote Audio is very lightweight compared to everything else on this list, but you could disable if it isn't needed.

The Client

UI Rendering

The SolidSDR user interface makes use of a lot of modern browser rendering features, but can be scaled back to improve the experience on older or lower power devices. Many of the same principles for server performance apply, in terms of CPU features, network connection, etc. However, there's also the additional concern of graphics performance. By default, SolidSDR takes advantage of GPU accelerated rendering. If performance is less than optional, there are a few things you can try.

These settings in App Settings will have the largest impact on rendering performance:

  1. Change the Peak Style. Points is the most demanding, followed by Line, and then None.
  2. Change the Fill Style. Solid is the most demanding, followed by Gradient, and then None.
  3. Disable Blur Effects. If hardware accelerated rendering isn't working, or the GPU is severely underpowered, the blur effects can be very slow. Otherwise, leaving them enabled might actually be faster.
  4. Disable Transparency Effects. Same as blur effects, but will have the biggest impact if hardware accelerated rendering isn't working since it will effectively disable that.
  5. Adjust Panadapter FPS and/or Waterfall line duration as noted above.

You can also enable the FPS counter to see what kind of difference your changes make. The counter has 3 numbers:

  • B shows the browser frame rate. This is the actual FPS for updating the screen. Ideally, this should match your configured refresh rate.
  • P shows the panadapter processing rate. This isn't the actual FPS for the panadapter, it's a measure of how quickly we're able to process incoming data. This should be higher than the B rate.
  • W shows the waterfall processing rate. Same as P, this isn't the actual FPS for the waterfall, it's how quickly we're able to process incoming data. It should be higher than the B rate.

Audio

Remote audio is very lightweight and should work well in nearly all configurations. DAX is far more demanding and shouldn't be enabled unless you're actually using it.

Clone this wiki locally