Stutter Issue

[brianrusso]

Creating this thread to discuss the stutter issue with Soapy

I tried an ethernet hat on a Pi 2 (to gqrx on a i5-1245U) and it made no difference, so I don't think it's a WiFi issue.

Has anyone come up with a solution for the stutter? I've played with gain but no luck.

[K7MDL2]

How do you define stutter? I can think of multiple types, likely each with its own causes:

1. AGC gain too high - I believe this to be the ADC overloading and no working mechanism to automatically lower it sufficiently.
2. CPU reading the stream and RPi sending the stream - Changing the sample type from int8, int16 or float can help avoid this point to throughput challenges for the particular hardware involved (CPU or network or both). This can include CPU utilization too high. The Pi running at > 80 or 90% tends to cause audio stutter. I avoid this by running the Pi as a server these days. - Also, at least in sdr++, enabling compression reduces the network data rate significantly and allows a a larger sample type. OpenWebRX on FM stations drives my Pi CPU over 80%.
3. Distortion
4. SoapySDR local vs SoapySDR remote - I find sdrpp server mode works pretty good but not SoapySDR mode. It appears to me SoapySDR is used in both cases, server using local.
5. High CPU or CaribouLite temperatures. They can run hot. Possibly CPU throttling kicks in?
6. Software instability - At one point I saw stuttering effects when I was still compiling different versions trying to find a working combo, the hardware stayed the same.

[ImDroided]

I have this issue also on pi3 headless, pretty much the only way I don't get stuttering is when I run SDRPP --server on top of SoapySDRServer --bind then use SDRPP and connect to the sdrpp server instead of the soapy server. I have noticed it has the CPU pegged in OpenWebRX my AGC is off so its not that.

My laptop is a i7 16gb ram so its not that. From the research I have done on other SDR apps it could be the audio driver in linux causing it

[brianrusso]

When I say stutter I mean that samples are being dropped somewhere.

Whether this is happening in the caribou, or between the caribou and SMI, or in Soapy.. I have no idea.

To your suggestions..

1. AGC - I've heard people mention this.. but I've tried adjusting gain settings in gqrx and it makes little/no practical difference. I'm using gqrx, and I'm frankly not convinced it's actually adjusting gain settings on the caribou.
2. I'm running SoapySDR on the pi (zero 2) and doing nothing else on it. Where are you adjusting sample data type? That might be the issue, but the math on that doesn't really make sense to me. Given that the SMI bus can handle several hundred mbps - shouldn't be a factor at 4MSPS / ~2.5MHZ bandwidth - but I'm willing to try adjusting this if you're able to provide more detail.
3. Not sure what you mean by distortion.. listening to local FM radio that works fine with a $15 RTL
4. Can you provide more detail on your sdrpp setup?
5. Caribou definitely heats up, but I'm not running it in adverse environmental conditions. (~70F ambient). If it can't handle that I'd say it's a bad design.
6. I definitely see software instability. I have to run SoapySDRUtil to probe it to 'wakeup' sometimes. Very inconsistent and lots of errors. I'd be okay with some 'alpha'-ness. My issue is I've never seen it work properly.

Thanks for your comments.

[K7MDL2]

With sdrpp I do not have to have SoapySDRServer running on the pi. sdrpp --server starts up and talks to Soapy on its own then handles the remote connection on its own. You can see it query and find the CaribouLite (not remote) driver as seen below form my startup text.

` 04-01 22:37:41.833 12853 12853 I CARIBOULITE Setup cariboulite_setup_signal_handler@cariboulite_setup.c:687 setting up signal handler MODEM Version: AT86RF215IQ (without basebands), version: 03Printing 'findCariboulite' Request: Printing 'findCariboulite' Request: {channel: S1G} {deviceid: 0} {driver: Cariboulite} {label: CaribouLite S1G[f4a09ad8]} {name: CaribouLite RPI Hat} **{serial: f4a09ad8}_** {uuid: 4d7830e7-28bd-4bf8-9f95-d65f9081a6f2} {vendor: CaribouLabs LTD} {version: 0x0001} [INFO] Initializing DeviceID: 0, Label: CaribouLite S1G[f4a09ad8], ChannelType: S1G

` In this case it is just S1G showing because it was the last device I had used. Change to HiF later and startup will show HiF channel. The highlighted parts are needed in OpenWebRX config. In my case HiF channel is serial: f4a09ad9. SoapySDRUtil will reveal the actual values in each setup.

My sdrpp client side app setup, here running on a windows 11 box.

Above I have connected and you can see the 2 CaribuoLite channels, S1G and HiF I can choose from. An RTLSDR shows up when connected also and works fine.

You can see the AGC checkbox in my pic above. I turn off AGC and use the Modem AGC gain slider and the popping will go away. Same for other SDR apps I have tried. The gain value will be different for each band. Put a preamp in front and you have to run the gain down to 1-20 range.

On a Pi4B sdr++ server runs about 10% CPU. I set Decimation to 8, I find the default of 0 not pleasing. IQ Correction gets rid of a center spike.

I have heard distortion in a few ways, sometimes due to weak signal, others due to wrong bandwidth.

The thermal images below are the system running at idle. NO SDR apps, no fan, just a heat sink. I have a case with cooler coming Tuesday. Its fan will blow across the CaribouLite as a bonus when I vertically plug it into the GPIO header. With OpenWebRX running an FM stations, I get 80% on the Pi4B. The browser is on a Windows machine. I just reduced the OpenWebRX max Client Sessions limit to 2, doubt it changes anything with just 1 connected.

The Sample type choices are Int8, Int16 and Float32. Compression saves bandwidth and can stop stuttering especially chooing Int8 sample type. I beleive Cubic SDR has similar options.

[K7MDL2]

It occurred to me grabbing these screen shots that until this afternoon I was not getting a lot of stuttering, it was very rare in fact. Now I am getting a lot. Enabling compression helps and lowering the sample type to Int8 mostly solved it. I did not have to do that earlier. Looking at the connection data rate it never goes much above 90Mbps. In past days I observed this to go as high as 250Mbps a the larger sample types.

What changed? Until This afternoon my Pi+SDR was on the same Gigabit switch as my client Windows machine. I moved it into another room near my attic VHF antenna patch panel. Now there is >100ft of shielded CAT6 running outside the house to get to my shack. I will have to move back into the shack and see if the data rate goes back up.

[K7MDL2]

I was correct. Moving the PI back to the same GB switch as the client machine in my ham shack raised my max connection rate to 250Mbps and no stuttering. The other switch was also a Gb switch and feeds the shack switch but the long cable run must be degrading things.

[konimaru]

When I say stutter I mean that samples are being dropped somewhere.

Whether this is happening in the caribou, or between the caribou and SMI, or in Soapy.. I have no idea.

Right now I'm happy with CubicSDR (no configuration issues). Can you send me the configuration you use for gprx? I tried a while ago but wasn't too happy. Thanks!

[K7MDL2]

Here is what I am using on the Pi4B now. Running it local on the Pi at 90% CPU and stuttering playing an FM station. Woudl run it on the PC but I have to sort out Python 3.9 vs 3.10 conflict for GQRX.

Here is Cubic SDR

[konimaru]

Hmm, admittedly this is just quick and dirty. Coupled a RPi3B with my laptop over a direct 1000Mbit link, CubicSDR and gqrx don't have any trouble playing (CS16). Need to move this to a real world network and check again. The only odd thing I noticed is that gqrx (2.15.8) receives a buffer queue worth of packets (after device start) and then does nothing for a while. Eventually (5..30sec) it will start playing. Not sure yet who is at fault. Given that CubicSDR shows immediate response/s I'm tempted to point at gprx ... but things are usually not that simple :)

The only stutter I ever experienced was when our WIFI link ran out of bandwidth and I simply couldn't get everything through.

@K7MDL2 what model is that IR camera you used?

[K7MDL2]

Seek Thermal Compact – All-Purpose Thermal Imaging Camera for Android MicroUSB, Black (UW-AAA). They have a Type C connector version which I should have got but just used a small USB micro to Type C adapter for my Android phone. You can zoom in and it has a limited mechanical focus/zoom, I did not take much effort to get a clear focus in those pics. 9 out of 10 times I use the thermal camera is to look at heat on PCB assemblies and RF amplifier pallets. Cinnamon rolls out of the oven make for interesting art shots.