I've been experiencing very choppy audio with the SDRPlay, and I've been experiencing it on several different PCs with a wide variance of operating systems, CPUs and amounts of RAM.

So far, it - inexplicably - works the best on a WinXP PC, Pentium single-core with 1.0 gig of RAM. I say the best because on a scale of 1 to 10, the problem is about a 3 on that PC while it's roughly a 1.5/2 on a quad-core Windows 8.1 Pro PC with 8 gig of ram, and it's effectively unusable on an Atholon CPU with 2.0 gig of RAM.

This happens on either 250/500 sample; anything above that is impossible.

Does the device require a multi-core PC to function well, or is there something in the setup that I can do to eliminate this problem? In none of the PCs does RAM usage exceed half and CPU usage on both the Win 8.1 Pro and WinXP PCs never really exceeds 30%, but yet the problem persists.

RF_Bandit wrote:This happens on either 250/500 sample; anything above that is impossible.

Can you elaborate on what setting exactly you're referring to?

Did you try if the same happens with HDSDR?

To small audio buffers (too low latency settings) can lead to audio dropouts of course. But alas there are like 100 other things between the USB port and your speakers that could cause dropouts/stutters. However, this could be one of the things your systems may have in common.

Thank you for your response, and I'd be glad to elaborate: I'm referring to the initial sample setting when you start the receiver, where you select anything from 250kHz through 8MHz. Performance is roughly the same if I choose either 250 or 500kHz, but the issue makes it impossible to listen when attempting anything more than 500kHz.

As an aside, moving the latency slider all the way to the right dramatically decreased the problem, but it's still there intermittently and it's led me to discover that, on record, the audio is distorted as though the input is too loud, regardless of how low I set the volume through the program or the master volume, and regardless of the gain settings. -59, -80 and -25 result in the "best" audio, but it's still pretty bad on playback.

I have not tried either HDSDR or SDR#, but I'm thinking that I might make the switch just to have a usable device; I've been using SDR-Console for a couple of years now with a Softrock Ensemble RXII and have thoroughly enjoyed it, but the current version is not only visually disappointing but is an extreme resource hog compared to the previous.

Hi RF_Bandit,I would certainly try HDSDR. This has the lowest resource requirements for any of the packages that you mentioned. There are several potential causes for what you are seeing, but dropped USB packets as a result of buffer overflows is quite likely with the machines that you mention. If the PC is unable to process the samples at the rate they are delivered, then the internal USB buffer memory on the RSP will eventually fill up and overflow. At that point, USB packets are lost. This leads to audio break-up. Whether this occurs or not is really determined by the PC chipset you are using (including the USB element of the chipset) and the efficiency of the software that you are running.If you want to handle up to 8 MHz of bandwidth, we would generally recommend a core i3 CPU (or higher) with a minimum of 2.5 GHz clock rate. Please note that the minimum ADC sample rate that is passed across the USB interface is actually 2 MS/s (with 2 channels of 14 bits). This means a minimum throughput of around 56 MBits/s. Lower sample rates are only achieved by down-sampling on the PC itself.

I have the original SDRPlay and can't really use it because of audio stuttering with my laptop. Performance will be fine for a few minutes when CPU usage shows at about 10%. After 5 or 10 minutes this will climb and once it goes over 50% the stuttering becomes very pronounced. I want the SDRPlay to sniff out new frequencies so I use a minimum of 5 MHz bandwidth. I have an i3 processor with a speed of 2.1 GHz. Are you saying that a new i3 laptop would need just a speed of 2.5 GHz to overcome my issue

Dear WHL,You don't say which SDR software you are using, but as previously noted HDSDR gives a lower CPU load than SDR# or SDR console. The actual RSP requires very little CPU cycles to actually deliver the data as is evidenced by the API test tool. The limitation is the load placed by the SDR package and whatever else you are using the PC for at the same time. Strangely, once the CPU starts to clip due to a momentary high peak load, it will not recover and quite why these SDR packages behave this way is not clear to us, but that is why things will work fine for a few minutes and then become unusable due to stuttering audio.It is hard to be certain precisely what PC spec will be adequate for your needs as it does vary with the performance of the USB element of the chipset, but generally, a core i3 at around 2.5 GHz should be adequate for 8 MHz of bandwidth (with HDSDR) as long as you are not trying to do much else with the PC at he same time. We cannot guarantee this to be the case though as different chipsets do vary at the same CPU speed, as they do for all applications.

The higher spec the machine, the less likely it will be that you will have problems.

You may have something else going on if after 5-10 minutes the CPU usage climbs from 10% to over 50% (mine always stays quite steady within a small range). Have you tried doing a CTL+Shift+Esc to start the Task Manager to see what processes are running and using resources, both before and after the climb?

If you use HDSDR it will show both HDSDR % usage and overall CPU % usage which can be helpful.

If latency, buffer and software do not turn out to be the issue, you can try adding in a better USB card. I have a very high end desktop machine, but even with 32GB memory and a high end i7 processor I had stuttering issues. I bought a high end 4-port Renesas based card from Amazon and now all my problems are gone. Many times, these stuttering issues are caused by a crappy USB chipset that just can't keep up with the huge amount of data demanded by SDRs (most of them, not just the RSP).

As the SDR world continues to evolve, the people writing the code are going to have to get smarter about minimizing data. I know SDR# now has a bit packing mode that reduces the data sent. This reduces the demand on the USB chipset, but adds some demand on the SDR itself (which, obiously works only on HIS SDR, the Airspy). Simon has also done a LOT to reduce overhead. He's working on version 3, which is even better, but version 2 has several controls that allow you to minimize data flow. Do a message search on his Yahoo Group and you'll find a lot of really good info about settings for SDR-Console to help your issue.

If I were you, I'd stop beating yourself in the head and buy a new USB card. Look at the Ettus Research website. They have a page that lists USB cards that work well with their SDR products. There are several different Renesas chipsets, some of which work better than others. Check their page so you don't get one from Amazon (or wherever you buy from) that has one of the low end chip sets. Here's the specific model I got: http://www.amazon.com/gp/product/B00HJZ ... detailpage. Note that it's very expensive, but I got that specific card for 2 reasons. First, it has 4 separate USB controllers so each USB port gets its own controller. I frequently run numerous SDR programs with 3 or 4 devices going at once, so my system requires that USB bandwidth and my only other choice was 4 separate cards, so this one made sense for me. The second reason was that it was very well rated everywhere I looked and others had tried it with great success with SDRs. So, if you're willing to spend more than the typical $20, it's an excellent solution. If you don't need 4 controllers, find one of the Renesas boards with the EXACT SAME CONTROLLER as the one I got (or a newer one) and you should be good to go.

Thanks guys. Some good ideas there. Apologies for kidnapping the thread but it is the same issue. I am using v2.3 build 2381 of SDR Console. I do have a lot open on my desktop so will close them and try again. I also notice that the waterfall is pausing as well as the audio issues. I never really got into HDSDR but will give it a go. Whoanellie -I will monitor processes as the CPU usage climbs and see what is causing itDavid - I am using a laptop and wouldn't mind investing if it fixed my issue. Is there a decent USB sound card that I should be using