SDR# SDR# crash/hang Windows 10 on Sample Rate change with RTLSDR

[thewraith2008]

Using Windows 10 64bit, does anybody see odd behavior with SDR# (1700, 1732) + RTL dongle crashing/hanging when changing 'Sample Rate' to anything less than 2.4 MSPS?

• Start SDR# (with RTL dongle).
• Open RTL configuration window (the gear button).
• Change 'Sample Rate' to say '0.25 MSPS?'.
• Close RTL configuration window.
• Press play in SDR#
• All looks OK, until see below

Problem #1 seen:
Changing frequency does not actually change frequency. Spectrum remains stationary.

Problem #2 seen:
When 'Stop' is pressed or on close of SDR#, SDR# hangs.

Tested with the cheap blue RTL dongles and the RTL-SDR.COM v3 dongles.

I'm not see this on Windows 7 Pro 32 bit.

 

[hamradionl]

I liked WIN 7 and welcome in the wonderful world of WIN10 - 64 you see things you never seen in WIN XP, WIN Vista and WIN 7 its humor
Only when use below 1024 MSPS like 0.9 or 0.25 MSPS i have SDR# crash and have this discuss long time ago with TSSDR
i think older SDR# version also have this crash below 1024. In the past mentioned this several times on SDR# forum, RRR forum and nobody responded, so i leave it and use 1024 as lowest value.

 

[Motik]

I have the exact same symptoms. Pretty annoying.

 

[thewraith2008]

It would be good if more people could test this out for me so I can see if issue is more wide spread then just me.

I have created a debug version of the standard SDR# RTL frontend and have pin pointed the problem to when the change frequency function is called in the RTL driver (rtlsdr.dll).

I would like to try and sort this crash/hangs out as they occur enough to be annoying and I would like to use a lower sample rate sometimes.

 

[hamradionl]

Try ask in the Airspy forum ?

This bug is also in the latest rtlsdr.dll ?

 

[thewraith2008]

Try ask in the Airspy forum ?

I'm looking for RTL dongle users and there would be less of them there I would think.

This bug is also in the latest rtlsdr.dll ?

Yes, I compiled rtlsdr.dll using one of the latest commits. Not the very latest, as changes would not make difference to issue anyway.

I need to add more debug traces as I go down this rabbit hole.

 

[poltergeisty]

I wonder if it's a permission issue? Is SDR# installed to the programs folder by chance and is SDR# set to run as Admin? If it's installed to the programs folder, try installing to the root of C drive instead. Since Vista I believe, the programs folder has been "emulated" and protected by the OS.

If it were me, I'd run VMware Workstation player with Windows 7 and use SDR# in there, etc. VMware has really good USB virtualization over something like Virtualbox. I know because I was able to used a Panda wireless USB WiFi dongle in Kali once to probe my own network for vulnerabilities, etc.

Just some food for thought if Win 10 is too much of a headache that I often read all too much about. Even with gaming Win 10 can be a PITA.

 

[thewraith2008]

Yes SDR# (and other sdr stuff) is run from a folder branching from C: drive.
I have tried running as admin with same result.
This Windows 10 PC with issue is only a test machine I use from time to time. I use Windows 7 normally and only rarely do I see SDR# hang/crash.
I do leave that PC running with TETRA decoding 24/7 just to keep it of the main PC so I can do other things.

If anyone is interested what I've found so far:
With the added debugging, I've pin pointed issue down to the driver function 'rtlsdr_set_center_freq'. This changes dongle frequency when spectrum is moved.
When a low Sample rate is used, this seems to take along time to process this function and will eventually report an error on return.
If SDR# is stopped before this function returns, SDR# will crash.

When SDR# first starts (and before play is started), the 'rtlsdr_set_center_freq' function is used as apart of the device initialization.
This executes with no lag/delay and always returns success (0).

If I block the callback function (which supplies IQ samples back to SDR#) the 'rtlsdr_set_center_freq' function seems to work without problems.
Only when SDR# is playing and (callback) IQ data is been transferred, there is a issue.

The error returned from 'rtlsdr_set_center_freq' function is : -9 or LIBUSB_ERROR_PIPE which comes from the libusb function 'libusb_control_transfer'.
libusb documentation shows: 'LIBUSB_ERROR_PIPE if the control request was not supported by the device'
I don't thing 'not supported by the device' is the case as it sometimes works (and works at higher sample rates)

Not sure if this means there is some issue with USB comms when there is control and data transfers occurring.
I've noticed that 'libusb_control_transfer' is apart of the libusb's synchronous (blocking) API for USB device I/O.
And the SDR# RTL frontend is using libusb's asynchronous (non-blocking) API for USB device I/O for the callback (bulk transfer) functions.
Not sure if this has anything to do with it. This low level USB stuff is outside my scope.