SM6FBQ / HackRF clone - History

Merge pull request #748 from ggatis/patch-1

Update hackrf_sweep.c

Merge pull request #805 from erikarn/ahc_20201108_fix_libusb_cancel

Fix libusb usage for at least freebsd around the worker thread and transfer cancellation

Handle hackrf_close() being called without TX or RX being started.

My previous commits didn't handle the specific case of hackrf_close()
being called without the transfers being active.

In this instance the transfers haven't been setup, so calling
cancel_transfers() returned an error.

Instead:

* refactor out the tx/rx stop command from canceling transfers
* send the tx/rx stop command without canceling transfers, since ..
* ... we can then destroy the transfer thread.

I may also need to put an explicit cancel_transfers() before the
call to send the tx/rx stop commands; I'll look at doing that
in a subsequent commit.

add 10ms sleep after stop

This seems to stop consumers that are doing quick back to back stop/start
(eg gqrx changing decode mode / filter bandwidth) from hanging the
device.

I now don't have any weird hangs on hackrf with gqrx/freebsd/libusb!

When things hang it isn't erroring out in any way; it just doesn't
start receive. It doesn't look like a libusb issue; I'd have to get
some USB bus sniffing to see what's going on behind the scenes.

Fix streaming hangs in consumers

* Update device->streaming to reflect whether we're streaming data,
rather than just whether the streaming thread is active.
The streaming thread is now always active!

Fix libusb usage for at least freebsd around the worker thread and transfer cancellation

On at least freebsd-13 trying to cancel a transfer whilst the libusb thread
is not running results in the transfers not completing cancellation.
The next time they're attempted to be re-added the libusb code thinks
they're still active, and returns BUSY on the buffers.

This causes gqrx to error out when one makes DSP changes or stops/starts it.
You have to restart gqrx to fix it.

After digging into it a bit, the libusb code expects that you're actively
running the main loop in order to have some deferred actions run in the
context of said main loop thread. This includes processing cancelled
transfers - the callbacks have to be run (if they exist) before the
buffers are properly cancelled and have their tracking metadata (a couple of
private pointers and state) removed from inside of libusb.

This patch does the following:

* separate out adding and cancelling transfers from the libusb worker thread
create/destroy path
* create the libusb worker thread when opening the device
* destroy the libusb worker thread when closing the device
* only add and cancel transfers when starting and stopping tx/rx
* handle cancelled transfers gracefully in the USB callback

Whilst here, also make the libusb device memory zeroed by using
calloc instead of malloc.

This fixes all of the weird libusb related buffer management problems
on FreeBSD.