Delay after rtlsdr_cancel_async

[Alexey Kruglov]

Hi.

I noticed there is a 1 second delay in librtlsdr between calling
rtlsdr_cancel_async and releasing from rtlsdr_read_async. I'm writing a
radio scanner and this delay limits scanning speed considerably. I
tracked the delay down to this piece of code in librtlsdr.c:

while (RTLSDR_INACTIVE != dev->async_status) {
	r = libusb_handle_events_timeout(dev->ctx, &tv);
[...]
	if (RTLSDR_CANCELING == dev->async_status) {
		next_status = RTLSDR_INACTIVE;
[...]
		if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
>>>>			libusb_handle_events_timeout(dev->ctx, &tv);
			break;
		}

The marked line is almost always(?) invoked when all the events are
already processed, hence it blocks for tv = 1 second. In fact I don't
understand what this `if' is supposed to do at all. I tried to modify
this line by changing the delay to 0 making it a non-blocking call
(leaving the timeout of 1 sec for the former
libusb_handle_events_timeout call). This worked with my project and the
1 second delay disappeared. So, I suppose, it's better to either a)
remove the whole `if' or b) make the latter libusb_handle_events_timeout
non-blocking as I did. I checked that b) works for me, and didn't test
a) yet.

The question is: what that `if (dev->dev_lost ...' is supposed to do?

And the two possible fixes for 1 second delay bug depending on the
answer are (diffs):
===
1630a1631
> 	struct timeval tv_nb = { 0, 0 };
1696c1697
< 				libusb_handle_events_timeout(dev->ctx, &tv);
---
> 				libusb_handle_events_timeout(dev->ctx, &tv_nb);
===

===
1694,1698d1693
<
< 			if (dev->dev_lost || RTLSDR_INACTIVE == next_status) {
< 				libusb_handle_events_timeout(dev->ctx, &tv);
< 				break;
< 			}
===



-- 
GPG fp: 6DFA 1186 7576 DE60 6CCB  EB39 AD81 1733 EEBB 970A