Server Buffer

[bvogt3000]

I have the SDR++ server setup and running on my network. All works great while having a wired connection, but when I am over Wi-Fi I get some choppy audio sometimes. With spy server, there is a buffer option that takes care of this issue. Is this something that could be added to SDR++?

[AlexandreRouma]

The differences is not buffering or not buffering, it's just that SDR++ server currently only supports full IQ mode. This has a much higher data rate going through and just is not gonna work over wifi.

[bvogt3000]

Ok, I was just curious as I am trying to be able to use it on my MacBook wirelessly. It actually is almost perfect over Wi-Fi using 5GHZ AX, aside from a few dropped packets from time to time. Figured a buffer might help that. Thanks.

[AlexandreRouma]

it can in case the issue is caused by frame timing but in this case it's almost certainly not enough bandwidth.

[bvogt3000]

A typical speed test for me run about 200Mbps to 700Mbps over my Wi-Fi to my server, so I do not think it is bandwidth. I think the issue actually has something to do Airdrop and some of the Apple ecosystem features on a Mac. It seems like based on pinging my server, when the Mac looks for Airdrop devices it causes the network jitter to increase therefore dropping some packets causing dropped audio. When I disable the awd10 network adapter (the adapter that controls Airdrop, universal control, etc) it works perfectly with both my Hack RF and my RTL Dongles. Also, when that is disabled my network jitter is much lower. After testing with SDR Console V3 server and spy server (which both have a buffer option) the higher jitter is not an issue when the buffer is set high enough. The audio is perfect even when my jitter increases. Being your server option is my favorite, I was just wondering if a buffer option could be added at some point or if you have it planned down the road?

[H6LS1S]

I have the same problem. Through Wi-Fi ( mikrotik hap ac2 ) on the local network, it is very problematic to work on bandwidth > 384kHz, the speed is 10-15Mb/s, compression does not matter. Is it possible to somehow improve the compression? I think for many, the indicator "real-time" is not as important as stability of work and bandwidth

[AlexandreRouma]

You're more than likely having large frame drops causing unpredictable delays (likely because of a low wifi signal). If you haven't already, try switching to 8bit samples. Also, very low latency is what by far most people want. Without inducing half second delays you won't be fixing the timing issues over WiFi at high rate.

As for improving compression, I'm sadly currently unable to break the laws of mathematics, so that will not be possible. The amount of data an SDR generate and the fact it's in separate block means it's usually quite hard to reduce the entropy even further. SDR++ uses ZSTD which according to previous testing does the best job of any of the common compression algorithms.

@bvogt3000 Adjustable buffering is planned but I cannot give any time frame as it's not a priority feature at all.

[H6LS1S]

You're more than likely having large frame drops causing unpredictable delays (likely because of a low wifi signal). If you haven't already, try switching to 8bit samples. Also, very low latency is what by far most people want. Without inducing half second delays you won't be fixing the timing issues over WiFi at high rate.

As for improving compression, I'm sadly currently unable to break the laws of mathematics, so that will not be possible. The amount of data an SDR generate and the fact it's in separate block means it's usually quite hard to reduce the entropy even further. SDR++ uses ZSTD which according to previous testing does the best job of any of the common compression algorithms.

@bvogt3000 Adjustable buffering is planned but I cannot give any time frame as it's not a priority feature at all.

I reorganized the 2-5G network in my house, since it works better (at least locally) when the Wi-Fi modules of my Mac and Dell work in the same range. I got local mesh speeds of 800 Mbps and 500 Mbps respectively, but that didn't fix the issue on Float32. Tested on two AirSpy HF Discovery / RSPdx devices

By the way, there is an interesting problem, while I use 8-16bit, everything is logical - more bit rate, more bandwidth is needed, I turn on compression - not that much better, but it works more stably. But when I enable Float32 the throughput drops to 10Mb/s from 80

My Stack: Dell Latetude E5570, i5 6440HQ, 16G DDR4L, Kali Linux MacBook Pro, M1, 16G, MacOS Mikrotik hap ac2

All equipment is within 5 meters of line of sight from each other. Therefore, the problem of weak Wi-Fi can be ruled out.

[AlexandreRouma]

800 Mbps and 500 Mbps

Throughput alone means nothing. Consistancy in the link delay does. The more rate you try to push through it, the more the chances for errors and the more inconsistent timing of the frames becomes. Also I don't have a mesh network, idk what kind of delays they have, but it probably doesn't help the situation. I've run a RTL-SDR from the other side of my house on an old crappy linksys.

but that didn't fix the issue on Float32

Why would you ever use float32 over wifi??? That's just asking for problems. if that was what you were complaining about then that's your issue.

But when I enable Float32 the throughput drops to 10Mb/s from 80

ZSTD is more happy with it, what can I say... It depends on so many things that you can't just show that and get any good info. Just the signals present on the waterfall, the hardware, the gains, etc are enough to change how well it's being compressed. The throughput is measured straight from the socket so it is accurate.

[deeptho]

I sometimes experience similar problems on a high bitrate wifi (800 mpbs). This is probably due to "beamforming" feature on my wifi. Especially at startup of a connection, there seems to be quite a lot of latency and lower bandwidth, causing problems, not only for sdrpp but also for ssh for example (poor interactive response for the first 10-30 seconds. Afterwards everything becomes fast.

However, with sdrp client on mylaptop I experience a strange problem, when using an sdrpp server on a fixed computer: Audio and screen updates stutter at a frequency of 1 or 2 per seconds and the gui becomes unresponsive. Sometimes just moving the mouse seems to fix the problem. Once the problem goes away, it stays away.

It could be triggered by the wifi problem above, but could also be related to pipewire (opening pavucontrol sometimes makes the problem go away even when not changing any audio setting). The problem only occurs when connecting to an sdrpp server, not when running with local device. It may be related to the network problems I mentioned above, but this also occurs after the wifi connection has been "warmed up". Also, ideally, the GUI should not freeze during such problems.

Despite this problem, I like sdrp and it has many nice features.

While I understand (and like) the need for low latency, having the option of buffering, with a small max delay (e.g., less than 100ms) would be a good option over wifi. And wifi is important, as it allows you to move a laptop close to the antenna when adjustments are needed.

Because I need this, and sdrpp -- server is unusual when far away from the wifi base station, I use a different remove solution: I running sdrpp client "locally" (on the computer with the airspy) and then view the result over wifi on the laptio with xpra.

This works quite well for both video and audio (but with a delay sometimes), except for one problem: sdrpp completely fails at videosync and starts using 500% cpu (5 out of 8 cores in use). That is of course unrelated to this issue. Other programs such as gqrx just work normally in this case.

So it could be there is some other problem as well.