Hi.
Device removal detection code in _libusb_callback in librtlsdr.c may be buggy. Every time we get any status other than LIBUSB_TRANSFER_COMPLETED (including LIBUSB_TRANSFER_ERROR) the code doesn't resubmit current buffer, and we get the real number of working buffers decreased by one. If that number goes down to 0, rtlsdr_read_async() will hang.
Linux version tries to control it by counting the number of LIBUSB_TRANSFER_ERROR buffers that came in row in dev->xfer_errors. But if we already have _one_ failed buffer during the whole transfer up to the moment, that counter will never reach dev->xfer_buf_num.
So it seems more straightforward to 1. count the failed buffers and rtlsdr_cancel_async() when it reaches 0 or some sensible threshold, and 2. maybe resubmit some kinds of the failed buffers other than LIBUSB_TRANSFER_COMPLETED, if it makes sense. I am not a libusb guru and it's not well documented in this part, so I am not sure about my second point.
Hoping some librtlsdr developers will appear on this list.
Alexey Kruglov wrote:
Every time we get any status other than LIBUSB_TRANSFER_COMPLETED (including LIBUSB_TRANSFER_ERROR) the code doesn't resubmit current buffer
That may not be a problem, depending on what assumptions librtlsdr makes..
Also note that a transfer with an error may also have successfully transfered some data, but not all that was requested before the error occurred.
- maybe resubmit some kinds of the failed buffers other than
LIBUSB_TRANSFER_COMPLETED, if it makes sense.
Only librtlsdr knows if it makes sense or not.
I am not a libusb guru and it's not well documented in this part, so I am not sure about my second point.
I know libusb well but I don't know the librtlsdr model by heart.
Naïvely I might think that once a single transfer fails then all other transfers should be cancelled - at the very least if the failure is because of the device disappearing.
//Peter
-
Alexey Kruglov -
Peter Stuge