Edouard Griffiths

@srcejon Hello Jon, can it be merged?

Did you set up the udev rules?

On this ticket the opposite direction was discussed: https://github.com/f4exb/sdrangel/issues/2082

I only had a quick look at the Qt state machine and I find it quite interesting. When the events and event handlers start to be rather complex it probably...

I see that `DSPDeviceSourceEngine` inherits from `QThread`. This is not the recommended way to work with QThreads. Instead the thread should be managed by the `DSPEngine` and `DSPDeviceSourceEngine` should be...

`initDeviceEngine` and `startDeviceEngine` should be combined into `startDeviceEngine` because we always have a sequence like: ```c++ if (m_deviceAPI->initDeviceEngine(0)) { m_deviceAPI->startDeviceEngine(0); } ``` And thus only a `DSPAcquisitionStart` message (removing or...

The essential of these commits is to make the various device engines truly asynchronous which shouldn't hurt. As part of it they are now using the recommended way to work...

I have noticed occasional issues when closing SDRangel while RTLSDR is still running. This may be due to the RTLSDR plugin not implementing the recommended way of using threads so...

This destroy() also hides QWidget::destroy() : ```c++ class RTLSDRGui : public DeviceGUI { Q_OBJECT public: explicit RTLSDRGui(DeviceUISet *deviceUISet, QWidget* parent = nullptr); ~RTLSDRGui() final; void destroy() final; ```

> Any other ideas to address it? Having the connect as QtQueuedConnection but I haven´t checked it yet Edit: well it is already a `Qt::QueuedConnection` so it seems it does...