Bug with ExtIO DLL for AirSpy: gain settings changing in the AirSpy upon HDSDR demodulator changes (such as to FM or AM or USB)
amontefusco opened this issue · 3 comments
A user reports what follows:
Whenever I change the receiving mode in HDSDR (such as to FM or AM or USB) I find that it resents the gain settings in the AirSpy, such that I need to move the slider(s) in the ExtIO control panel to put them back to where they should be. Keep in mind, it doesn't reset the position of the sliders, just the internal variables that hold the gain values. By manually moving the slider in the ExtIO control panel (or even just clicking on the slider) it refreshes the gain variables in the ExtIO DLL, and puts the gain back where it was the last time you had moved the slider.
I should not need to refresh the internal variables in the ExtIO DLL every time I change the receiving mode in HDSDR. A correctly functioning ExtIO DLL will hold the values of its internal variables, until changes are applied directly to the ExtIO DLL control panel's controls.
I'm not sure, if this is directly a bug in your DLL, or if it's due to an incompatibility with the current version of HDSDR, and how it communicates with the DLL. I'm sure there have been many updates to HDSDR since you last updated your DLL file (which was back in 2017). Maybe it fully worked without bugs back at the time you originally compiled it, but it is having this problem now.
Please fix this.
I didn't manage to replicate the bug with HDSDR 2.76a and my extio_airspy_cmake_mgw-v1.0.7.dll.
Alas, the user didn't say which software releases he is using.
New report from user:
There was a slight mistake in what I reported. I hadn't done enough testing at that time, and I've done more testing since then. It's not exactly when you change modes that causes this bug. It's when you change the audio output sample rate in HDSDR (like set it to 12000Hz or 48000Hz). And each mode stores the last used audio sample rate for that mode, so switching modes can cause output sample rate switching (which triggers this bug). So it also happens if you change the output sample rate but don't change modes. However, if all modes are set to the same sample rate, so that changing modes does not cause a change of output sample rate, then the bug does NOT happen when you change modes.
The behavior described above could be due to the inability by HDSDR to write the Airspy Extio DLL configuration file.
Such configuration file is named AIRSPY.txt and, in W10 systems, assuming you have a standard HDSDR installation, it is usually located in
c:\Users<user_name>\AppData\Local\VirtualStore\Program Files (x86)\HDSDR
in any case, it can be retrieved submitting the following command
dir c:\AIRSPY*.txt /s
The reason the defect is showing up when the output sample rate is due to the fact that HDSDR reset the DLL on that event (closing and reopening hardware recalling the specific callbacks) so that the DLL code is forced to read again the configuration file with old values.
BTW, it should be even noticed that each time HDSDR gets restarted the old values are used.
Moreover, if the above holds, one should see that starting HDSDR as Administrator rights, everything works as expected.
Another test is to copy everything has been installed in C:\Program Files (x86)\HDSDR in a temporary directory under the user's desktop and start HDSDR from that directory, so that the AIRSPYxxxx.txt files is created just there, so hopefully in a place where it can be freely written.