-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor flow graph management #111
Comments
Minor update: commit 76afa0a and its parent add plumbing for telemetry messages directly from devices (no demodulator), but it's not at all applicable to non-telemetry. |
I would prefer not to have lazy initialization of devices; I've seen many drivers that are flaky when opening or reopening the device, and I would very much like the option to open the devices on startup and keep them open as ShinySDR works today. Otherwise these all sound like great ideas. |
@quentinmit It sounds like you're mostly asking that they not be closed unnecessarily, is that right? I wasn't planning to; the change to device handling versus the current situation will be that if ShinySDR specifically detects that no samples are coming in (or a more obvious error condition) it'll try reopening the device, so as to help with unplug/suspend. Auto-closing devices might be interesting for some use cases but if I implement that it'll be an option. And they'll still all be opened on startup, but if one device isn't found it won't prevent the server from coming up as currently happens. |
Yeah. It sounded from your discussion of "these are explicitly active sinks" that any devices that weren't a dependency would be closed. Something needs to intentionally keep the devices open even if nothing is connected to them (which probably means swapping in a null sink, now that I think about it). |
There are a number of things I want which are not feasible to implement given the current way in which the GR flow graph is managed (in
shinysdr.i.top
,shinysdr.i.receiver
,shinysdr.devices
), such as:My current plan is that this should be handled by having a much more generic layer on top of GR which has the notion of "these are explicitly active sinks" (such as a telemetry demodulator or an audio output being streamed) and dependencies from those nodes followed back to the device. This architecture, if successful, would also possibly work for some other improvements:
The text was updated successfully, but these errors were encountered: