BatchDrake
SigDigger steals device on startup
Say that you have SigDigger running using a physical SDR device (e.g., rtlsdr). Then, you decide that you want to start a second SigDigger instance to examine a previously recorded file. The moment the second SigDigger starts, it probes for devices which causes the first instance to lose it's access to the physical device.
The result is:
- first SigDigger receiving data
- second SigDigger is idle, waiting for a device to be selected and capture to be started
I'd expected that the first SigDigger would be uninterrupted unless the second instance of SigDigger actually attempts to use the physical device due to a user action.
It's odd because I'd expect that as well. It seems to be related to the SoapySDR RTL-SDR driver. I'm temptatively marking this as device specific until I can test it myself at home.
Does this happen with other software, like Gqrx? It would be interesting to see what happens if you attempt to use SigDigger and rtl_fm at the same time too (the latter uses librtlsdr directly I think).
In short: yes, it happens.
I ran:
# rtl_fm -f 95.5M -M wbfw | pv > /dev/null
It was producing about 46 KiB/s according to pv.
Then, while that was still running, I started SigDigger. The rate dropped to 0 near the end of the splash screen (maybe during the "loading profile" part?).
Does it also happen the other way around? Using SigDigger and then running rtl_fm? If it does, I think we may be dealing with a librtlsdr thing here.
Yes, it happens to the second application regardless of it is SigDigger or rtl_fm.
The rtl_* tools are kind of dumb, so I 'm not surprised that it just blindly grabs the device. But, I'd expect Soapy to prevent that if possible. If only to allow multiple Soapy consumers concurrently on different sources.
I don't know how exactly device enumeration works. Does it make sense to enumerate devices on SigDigger startup before the user did anything?
I don't know how exactly device enumeration works. Does it make sense to enumerate devices on SigDigger startup before the user did anything?
Device enumeration is rather slow, and at least I need it to populate the RTL combo in the source dialog. I could do it on demand, but that would freeze (or at least, disable) the combo until all sources are discovered.
The problem however is probably not enumeration, but enumeration + instatiation (which I need in order to retrieve device parameters like gain, accepted sample rates, etc). An alternative could be to cache these parameters in the configuration folder and trigger instatiation only if a new device is found. Maybe this can be done directly in https://github.com/BatchDrake/suscan/blob/develop/analyzer/source.c#L684, without even touching SigDigger. However, this would be a full feature on its own (an interesting one, because we would improve startup time by a lot)
On Mon, Jan 04, 2021 at 12:56:49 -0800, Gonzalo José Carracedo Carballal wrote: ...
The problem however is probably not enumeration, but enumeration + instatiation (which I need in order to retrieve device parameters like gain, accepted sample rates, etc).
Ah, that's probably it then. Soapy needs to open the device to get the parameters, but doing that "steals" it from the existing consumer.
An alternative could be to cache these parameters in the configuration folder and trigger instatiation only if a new device is found.
Plus a sanity check when capture is started and therefore the device is open anyway. I'd expect a failure to validate to kick me back to the sources dialog.
The source dialog caches quite a bit of data already (e.g., file source path and format), so this seems like reasonable approach.
Alternatively, if the problem is narrowed to multiple-SigDiggers only, the SigDigger (or suscan) instances could "cooperate" to avoid stepping on each other by implicit actions (like program start). I think it'd be more than enough if the second and subsequent instances simply label the physical device as "busy" and provided a "use anyway" UI button. That way, start up would skip instantiating them unless the user really wants to touch them.
This would probably be good even for less problematic devices since I expect lots of agony if someone's capture on a device got ruined because they started SigDigger to look at something else and accidentally touched the same device in-use device instead of another device they intended to use. (I'm assuming multi-device setup here.)
Of course this could be combined with the caching idea or even just forwarding it via some RPC mechanism between suscan instances ;)
Ok, I might be dreaming of "perfect" here, but being able to start a second SigDigger without it interfering with existing device usage is all I ask for :)