The version from May 6 works terribly

[T-Shilov]

Bug. I have Debian v. 10 running steadily for a long time. But when I installed your version of SoapySDRPlay3 from May 6, it regularly causes Debian crashes. Once every few days, it stops working. The system stops responding and does not respond to the keyboard. The network also does not work and does not ping from the outside. But there is no kernel panic. The OS froze as if rooted to the spot. Ctrl-Alt-Del and "Magic Button" SysRq/Printscreen don't help. Only Reset helps. When I stopped using your software, Debian again began to work as before, steadily.

Disadvantage. The process of your SoapySDRPlay3 from May 6 consumes a very lot of resources - 30% or more. Other Soapy consumes a units of percent.

[fventuri]

Thanks for reporting this very serious bug @T-Shilov

I am not running Debian v. 10 here (I use Linux Fedora 34), but I did take a look at the CPU issue you mention in your comment.

In order to be able to easily compare my results with yours, I ran the following command in a terminal (the RSP model I am using here is an RSPdx):

SoapySDRUtil --args="driver=sdrplay" --rate=2e6 --direction=RX

The command above streams samples from the RSPdx at a sample rate of 2Msps using the SoapySDRPlay3 module.

In another terminal (with the streaming still running), I ran the command top to see what process was using most of the CPU, and I noticed that it is the process called sdrplay_apiServ (see screenshot below):

The process sdrplay_apiServ is the SDRplay proprietary API server and unfortunately I know very little of its inner workings.

I would suggest, if you don't mind, to run the same test with SoapySDRUtil and top on your computer, and if you confirm my findings, you may want to create a support case directly with SDRplay here: https://www.sdrplay.com/help/ (there is no charge for their support for registered RSPs); in that ticket after a description of the problem, you may want to reference this comment thread.

Regards, Franco Venturi

[T-Shilov]

Oh, yes, dear friend, I completely agree with you. In order not to disrupt the operation of my main server, which runs OpenWebRX in mode 24/7, let me prepare a separate computer on which I will install the SDRplay RSP1A receiver and your the SoapySDRPlay3 module. After that, I will present you with the necessary data about the operation of the SoapySDRPlay3 module. Ok?

[fventuri]

Thanks @T-Shilov - I am interested to see your results.

Franco

[T-Shilov]

So, I installed a new clean Debian version 10.10 with 64 bits on a separate computer. The computer uses an i3@540 processor. I connected two receivers to this computer:

1.. RTL-SDR v3.

2. SDRplay RSP1A

The reception band of these receivers is set to be the same: 2 MHz.

Very important note: I did not connect the antenna to these receivers. That is, the receivers do not receive radio signals, they only rest.

Now take a look at the CPU resource consumption of these receivers:

1. RTL-SDR uses only ~3%, this is not much and very good:

2. SDRplay uses ~33% and ~36%. This is a colossal gluttony!

In addition, I have already said that when using SDRplay, the operating system periodically certainly falls into a coma after a few days and stops working and being managed. To bring the system out of this state, I have to press the Reset button.

When I disconnected SDRplay from the computer, the gluttony disappeared, and the operating system began to work stably again for many days.

These are huge software disadvantages for this receiver.

Dear friend, It must be improved to reduce its voracity and the stability works of the operating system!

[fventuri]

@T-Shilov Since your screenshots show that the CPU is used by the process sdrplay_apiService (not sure why the first screenshot has two instances running), did you create a support case with SDRplay (https://www.sdrplay.com/help/) as I suggested in my comment 10 days ago? (https://github.com/pothosware/SoapySDRPlay3/issues/41#issuecomment-875973388)

Franco

[T-Shilov]

Another example is on a real server running RTL-SDR = 7 pieces and one Airspy Mini. The Airspy Mini receive a 3 MHz wide band, but also consumes a little: only ~9%:

not sure why the first screenshot has two instances running

Yes, that's right, 2 threads are always started. I don't know why.

did you create a support case with SDRplay (https://www.sdrplay.com/help/) as I suggested in my comment 10 days ago?

No, I haven't written it yet. I do not know how to correctly describe this annoying situation to them. But if you prepare a competent text of the appeal for me, I will definitely contact them.

[fventuri]

@T-Shilov - I would just open a support case with SDRplay reporting exactly what you see, i.e. that the sdrplay_apiService is using about 30-35% of the CPU when streaming, while other devices like RTL-SDR and Airspy use much less CPU. You may also want to attach these screenshots you took and the OpenWebRX configuration you are running there.

I would then ask them why the CPU is running so high and what can be done to resolve this problem, since they are the ones who wrote sdrplay_apiService, and therefore they should be able to help troubleshooting it.

I imagine that they would ask you for more information or tests like I did earlier, and hopefully this will help find the root cause and a good solution.

I am also mentioning @SDRplay; this way he can reply directly on this thread, if he has time to look into it.

Let me know how it goes, Franco

[SDRplay]

If you can tell me the precise SoapySDRUtil command you used (as per Franco's suggestion above) to see the high CPU load and what OS/architecture you are using, I can try to reproduce the issue.

Best regards,

Andy

[alphafox02]

Judging by screenshots it appears both radios are configured within Openwebrx and that Openwebrx is being started up and “using” the SDRs at which point the comparison in CPu usage is happening.

[alphafox02]

As a quick test, may or may not be helpful, I have an RSP1A plugged in to an x64 laptop w/ DragonOS. I’m running SDRAngel with current native use of the API3 built in. Im seeing no more then 5% CPu usage on the sdrplay_apiServ with about 9% from SDRAngel. Receiver is on.

I shut it all down, unplug the rsp1a and plug in an rtlsdr. Start back up SDRAngel and now I have about 20% usage.

If I sit and watch long enough the numbers come out about the same.

Now if I jump over to Cubic SDR I get about 9%~ CPu usage on sdrplay_apiServ. This using SoapySDRPlay from like June 2020 so I’ll try the latest and do comparisons. Maybe it’s something in the way openwebrx is using Soapy and thus making more work for the api? Dunno, but thought I’d try and help test.

[alphafox02]

Did a uninstall of the old sdrplay soapy 7 module, downloaded the latest from here using git. Compiled and installed, restarted cubicsdr and I have about %20~ CPU usage.

Edit: I uninstalled the latest, put back the old sdrplay soapy and I get basically the same exact 20ish CPU numbers. I looked too quickly in my comparison and I think the 9% was actually Xorg cpu usage.

Anyways, hope that’s helpful. In my quick test with cubic SDR which uses Soapy it seems I get the same CPU usage regardless of SDRSoapy (7) versions I use.

[SDRplay]

The service will have a different load depending on what it's being asked to do - LowIF vs ZeroIF for example or whether decimation is used and what sample rate is in use, whether AGC is on/off, etc.

So without knowing what the service is being asked to do it's almost impossible for me to comment on the CPU load.

If you can get some specifics on the setup or use the SoapySDRUtil method as Franco showed, then I can run some tests with those settings.

Best regards,

Andy

[fventuri]

To try to rule out as many variables as possible, I compiled the example from the SDRplay API specification guide (https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.07.pdf - chapter 4), ran it on my PC with the RSPdx (without any antenna connected), and the top command shows that the sdrplay_apiService process uses about 35% of the CPU:

My PC here is an i7-5500U running at 2.4GHz, and the OS is Linux Fedora Core 34.

The source code of the example from the API specification guide (which is exactly what I ran) is attached.

Franco

sdrplay_api_example.zip

[SDRplay]

@alphafox02 I think you've misunderstood what I was saying about SoapySDRUtil - I've seen your question to Jakob and I wasn't talking about openwebrx. Near the beginning of this thread, Franco suggested that you run SoapySDRUtil as a way by which to check the CPU load for a given setting of the SoapySDRPlay library...

SoapySDRUtil --args="driver=sdrplay" --rate=2e6 --direction=RX

If you can run this (making sure that you are using the very latest version of SoapySDRPlay library so that we're all on the same build) and let me know what you see then I can do the same. It's very similar to what Franco has done with the code example, but uses the existing library that you are working with. So either of the two options are fine.

Also, @fventuri can you run htop and show what each core is using please?

Best regards,

Andy

[fventuri]

@SDRplay - here is the screenshot with htop:

Franco

[T-Shilov]

@SDRplay please here is my test:

# SoapySDRUtil --args="driver=sdrplay" --rate=2e6 --direction=RX

Operating system: Debian 10.10 / 64 bit CPU: Intel i3-540 3.06 GHz Receiver: SDRplay RSP1A original

[SDRplay]

If I remember right, 2 MHz should be using Low-IF, can you also try 2.1 MHz sample rate - thanks

[T-Shilov]

Ok, for this I have to specify this option? --rate=21e5

[SDRplay]

That or 2.1e6

[T-Shilov]

SDRplay: please, test to 2.1 MHz and 10 MHz:

[SDRplay]

ok, so this is more along the lines of what I would expect. 2 MHz Low-IF starts off life as a 6 MHz sample rate and then there is a down conversion and de-rotation process with filtering which is what is putting up the CPU load - you can see that 2.1 MHz Zero-IF is a 3rd of the CPU load than 2 MHz Low-IF - 10 MHz Zero-IF appears to be the same load as 2 MHz Low-IF, that is more surprising unless there is something I'm forgetting about.

Has anyone compared this to Windows performance?

[SDRplay]

@fventuri what would be the command line option to disable the AGC loop?

[fventuri]

@SDRplay - as far as I know the command line utility SoapySDRUtil is very general and does not have a specific option to disable IF AGC; it does have a command line option called args that can be used to pass arguments to the underlying device module; however the SoapySDRPlay module writeSetting() method does not have an option to disable IF AGC, since that functionality is already provided by the setGainMode() method in the same module (https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L455).

After dinner I plan to run some tests with the SDRplay API specification guide example code, since it is very straightforward to make changes there (and it can be easily compiled on Windows), and I'll report on my findings later on.

Franco

[fventuri]

I just ran a few tests with a slightly modified version of the example from the SDRplay API specification guide, and I noticed that by the default that example sets a sample rate of 8MHz for the RSPdx, which explains the high CPU usage I noticed yesterday - once I lowered the sample rate to 2MHz, the CPU usage went down to about 11% in ZIF mode.

Anyhow the quick table below has the results of my tests for several different combinations of sample rate, IF frequency, and IF AGC (notice that the CPU usage according to top was fluctuating +/-2% during each test):

fs=8M,IF=ZIF,AGC=0   35%
fs=2M,IF=ZIF,AGC=0   11%
fs=2M,IF=1620,AGC=0   6%
fs=8M,IF=1620,AGC=0  17%
fs=8M,IF=ZIF,AGC=4   37%
fs=2M,IF=ZIF,AGC=4   13%
fs=2M,IF=1620,AGC=4   7%
fs=8M,IF=1620,AGC=4  20%

The source code for the modified version of the example from the SDRplay API specification guide that I used for these tests is attached.

Franco

sdrplay_api_example.zip

[fventuri]

After the tests above which show that the sample rate is the variable that mostly affects the CPU usage, I ran a similar set of tests using SoapySDRUtil with different values of the sample rates, and I noticed that for an input sample rate of exactly 2Msps, the SoapySDRPlay module selects an output sample rate of 6Msps and an IF=1620KHz, thus causing the high CPU usage, while if I select an input sample rate of say 2.048Msps, then the output sample rate is the same 2.048Msps, and the IF=0 (and the CPU usage is much lower).

I suspect the reason for this behavior is based on this comment back in our discussion in January of last year: https://github.com/pothosware/SoapySDRPlay2/issues/62#issuecomment-575004167 (for those unfamiliar with the whole discussion we had, I suggest reading the whole thread).

I wonder if, based on these tests and the high CPU usage we are noticing, we should revisit that discussion, or if we should just leave the code unchanged, and suggest @T-Shilov and other OpenWebRX users to select a slightly higher sample rate, for instance 2.048MHz.

Franco

[T-Shilov]

@Franco

... or if we should just leave the code unchanged, and suggest @T-Shilov and other OpenWebRX users to select a slightly higher sample rate, for instance 2.048MHz.

I don't quite understand you... Are you suggesting that developers SDRplay announce to the whole world that they are not able to eliminate these errors in the software, so that customers no longer buy defective SDRplay receivers from the this company???

[alphafox02]

@T-Shilov Not sure how you made the connection to defective hardware, I think you missed the key word SoapySDRPlay, not the SDR API or hardware.

@fventuri I’ll keep an eye on this ticket and see if there’s any update to SoapySDRPlay or I’ll change sample rate on my end.

[SDRplay]

yeah I think @T-Shilov has got the wrong end of the stick. @fventuri was just explaining why 2 MHz has been done the way it has. The SoapySDRPlay library can't make assumptions as to what type of signals you are looking for, so for 2MHz sample rate it uses Low-IF which means there is no DC spike and therefore is optimum from a signal analysis perspective. However, there is extra processing required for Low-IF vs Zero-IF and so if you are not worried about the DC spike, then a sample rate > 2 MHz (like 2.001 MHz) will select Zero-IF. He was asking if this should be changed. I think more data is needed before deciding on what needs to happen.

If I run @fventuri's code on my Windows machine then it only takes a few % CPU load, so what I really need is a comparative run on similar hardware between Windows and non-Windows - it's something I can do, but not at the moment - I can update the ticket when I've got a chance to collect the data and do some analysis. I've just got a heavy load on, so it might take me a bit of time to get the data.

[T-Shilov]

@alphafox02 Defective equipment?? Hmm, to find out the problem, I sequentially replaced:

**1. CPU

2. Motherboard
3. Memory
4. Hard disk**

What else should I replaced??

[US1GHQ]

Good evening, i am try using rsp1a and I also ran into the fact that the process soapy sdrplay_apiService load my CPU from 30-37% I need 0.25 and 1MHz bands (not 2 or 4MHz) My configuration is Core I7 920 CPU and OpenWebRX 1.0, i am run command for testing SoapySDRUtil --args="driver=sdrplay" --rate=0.25e6 --direction=RX later SoapySDRUtil --args="driver=sdrplay" --rate=0.5e6 --direction=RX and SoapySDRUtil --args="driver=sdrplay" --rate=1e6 --direction=RX and i see next results so why cpu load i high at small bandwith? Now i compelled use RTL SDRs but i want use the RSP1a for my WebSDR, thanks Thanks and sorry for my English =)

[US1GHQ]

I need to buy one more receiver. But maybe I should buy Airspy instead of SDRplay, which does not have such problems, and it loads the processor a little? I am at a loss: - (

[fventuri]

@T-Shilov @Excalibur201010 I understand your concerns; I just created a new branch called ZIF; the code in that branch has a new device parameter called force_zif that, when set, forces the IF to be zero when the sample rate = 2Msps (and hence it runs the RSP with an internal sample rate = 2Msps too). You can find the new code here: https://github.com/pothosware/SoapySDRPlay3/tree/ZIF

Once you build the SoapySDRPlay driver from the code from this new ZIF branch, you should be able to enable this new option by running the usual SoapySDRUtil tests as follows:

SoapySDRUtil --args="driver=sdrplay,force_zif=1" --rate=2e6 --direction=RX

I ran a couple of tests here a few minutes ago, and it looks like the CPU usage is significantly reduced; please give it a try on your computers and let me know if you notice any improvement.

Franco

[fventuri]

@SDRplay I just ran a quick test with the example code (attached below) under Windows 10 with the exact same hardware configuration that I was using for the Linux tests last night (since my PC here is configured dual boot Linux/Windows), and on Windows 10 the first test with fs=8M,IF=ZIF,AGC=0 showed that the service sdrplay_apiService was using only 7-7.2% of the CPU according to TaskManager, while the CPU usage with Linux was about 35%, according to top.

I don't have time to run more more tests tonight since it is getting late here, but perhaps this high CPU usage issue is something specific to Linux.

Franco

sdrplay_api_example_windows.zip

[T-Shilov]

...while the CPU usage with Linux was about 35%, according to top. I don't have time to run more more tests tonight since it is getting late here, but perhaps this high CPU usage issue is something specific to Linux.

That's wonderful, Franco! So, your testing also confirms that developers undoubtedly need to improve the software for Linux!!!

[SDRplay]

@fventuri can you try bulk mode on both Windows and Linux please? I'm also running some other tests so would be good to compare results after you've been able to do that.

[fventuri]

@SDRplay Switching transfer mode to bulk didn't seem to make much of a difference; these are the CPU usage results in Linux and Windows 10 (program compiled in 32bit mode) using the example code from the SDRplay API specification guide running with the same sample rate (8MHz), zero IF, and AGC disabled:

OS=Linux,TM=ISOCH   35%
OS=Linux,TM=Bulk    35%
OS=Win32,TM=ISOCH    7%
OS=Win32,TM=Bulk     6.5%

The modified example source code I used for these tests is attached below (it should compile and run under both Linux and Windows).

Franco

sdrplay_api_example.zip

[fventuri]

At this point, since I have been consistently able to reproduce the CPU usage in Linux by just running SDRplay provided example code, I am not sure if this is an issue that belongs specifically to the SoapySDRPlay driver.

I think the right place for this work should be under an SDRplay technical support case that @T-Shilov and @Excalibur201010 can open at https://www.sdrplay.com/help/ - in that ticket you can just refer to this discussion thread.

Franco

[alphafox02]

If it helps narrow something down - I just checked with an RSP1A in Linux using DragonOS with the latest SDRAngel which now has native sdrplay API support and found that CPU usage was extremely low as compared to using something that relies on the Soapy backend. Maybe Soapy itself needs looked at.

[fventuri]

@alphafox02 Did you compare it with the equivalent configuration using the zero-IF code (i.e. with the actual internal sample rate set to 2Msps) as per this comment https://github.com/pothosware/SoapySDRPlay3/issues/41#issuecomment-884603044 ?

Franco

[fventuri]

I just ran the latest version of SDRangel here streaming from the RSPdx with a sample rate of 2Msps and zero IF, and I see that the process sdrplay_apiService is using about 6.3% of the CPU: which is not too different from the results I showed in the table in this comment: https://github.com/pothosware/SoapySDRPlay3/issues/41#issuecomment-882946608

Franco

[alphafox02]

@fventuri i missed that configuration you mentioned. I was just curious what would happen with the CPU usage if I didn’t use Soapy at al and I stopped at the point where I saw low usage and thought, well that looks good. Now I see where you made changes in SoapySDR and from what I see, you also got low usage using certain configurations which is probably the equivalent of what SDRAngel was doing I assume?

[SDRplay]

On Linux, you need to divide the CPU load shown by the number of cores on the machine - are you doing this?

400% on Linux == 100% on Windows for a quad core machine.

I tried a LibUSB driver on Windows and saw no difference between the hardware driver version of the API and the LibUSB version. Unless anyone has any different data I think you can close this @fventuri

[T-Shilov]

@SDRplay In any case, and regardless of the number of cores, the CPU load of the sdrplay_apiServ process is several times higher than that of other models of SDR receivers (Airspy, RTL-SDR) with the same reception band. This is observed in Linux.

[SDRplay]

I'm confused, if you agree that the Windows CPU loading is ok and the Linux numbers reported are n times the Windows number (where n is the number of cores in the machine) then that is the same as Windows, so I guess I don't understand the issue.

I can't speak for other SDR libraries and what filtering or conversion processes are being used, so if you are trying to compare our library directly with another SDR library then that's not an apples to apples comparison.

[T-Shilov]

Ok, let's leave the Windows alone. I deleted it. Compare the performance of SDRplay with Airspy and RTL-SDR. Why is there such a huge difference in CPU load? This was demonstrated above.

[SDRplay]

I'm not sure how I would know - I have no idea what those other libraries are doing or not doing.

[jketterl]

I can tell you one thing those libraries are not doing: They're not filtering, shifting or decimating the data, at least not in their most common use cases. Typically, they just pass the IQ data coming from the device without modifying it in any way.

[fventuri]

Thanks @SDRplay, @jketterl, @alphafox02, @T-Shilov, and @Excalibur201010 for your useful comments.

At this point I am going to go ahead and close this issue since we found out that:

• the difference in CPU usage between Linux and Windows is due to the different way top on Linux and TaskManager on Windows display CPU usage - on my system with a four core CPU, a CPU usage of say 8% with TaskManager would translate to approximately 32% with top.
• the difference in CPU usage between SDRplay and other devices is likely due to other tasks like filtering, shifting, and decimating the IQ stream, which is something that other simpler devices like RTL-SDR don't seem to do (a more thorough investigation is outside of the scope of the SoapySDRplay module)

Finally, if the CPU usage is still a concern, here are a couple of ways to reduce the CPU usage using the SoapySDRPlay module:

• if possible select a sample rate slightly above 2Msps; this morning I did some quick math, and since the audio sample rate is typically 48kHz, it might be interesting to try out an I/Q sample rate of say 2.16Msps (48kHz 45), or perhaps even 3.072Msps (48kHz 64); this latter value could help reducing the overall CPU load because no rational resamplers should be needed to go down to 48kHz
• if the client application absolutely requires a sample rate of 2Msps, another option is to use the code in the ZIF branch (https://github.com/pothosware/SoapySDRPlay3/tree/ZIF), and add the argument force_zif=1 to the device string, as explained in my comment a few days ago - if you do find that this option is useful and it helps with the CPU usage of the sdrplay_apiServer process, please let me know, and, if there's enough interest in having this option available in the master branch, I can go ahead and merge those changes, since they do not change the current behavior for the rest of the users.

Franco

[T-Shilov]

@Franco Why did you unceremoniously close this discussion?? This is tactless in relation to other users who do not believe that this problem has been solved, and they want to express their special opinion. I opened this discussion, so only I have the moral right to close it.

@jketterl Dear Jakob, I am grateful to you for participating in the discussion on this issue. I remember your warnings about problems and artifacts when using the SDRplay RSP1A receiver. But I hoped that I would be able to overcome these problems myself. Unfortunately, it did not work out that these problems do not depend on me, but on the software developers for this receiver. Unfortunately, I do not yet observe the necessary interest of developers in solving the detected problems. These are two problems, I reported them in the initial message - 1) Regularly Debian fatal crashes. 2) Gluttony process of sdrplay_apiServ.

No one has paid attention to the first problem yet. I think that both of these problems are somehow connected.

[T-Shilov]

@SDRplay So, will your company correct the software flaws described here? Or will you leave them unchanged? I want to get an official response from you.