Refactor flow graph management

[kpreid]

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:

• Ability to reconnect to devices, due to glitches, unplugging, or starting up before it is plugged in.
• Multi-user/multi-session needs multiple audio output buses.
• Demodulators should be able to be explicitly destroyed (#87).
• Devices, demodulators, etc. should be created asynchronously (#86).

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:

• Better handling of non-GR data flow, such as telemetry messages (particular example: I would like to display data from APRS-IS, which involves no RF at all).
• Allow multiple receivers to share filter stages to reduce total CPU load (e.g. select the CW band from a much wider analog bandwidth, and then select two arbitrary channels within it).

[kpreid]

Minor update: commit 76afa0a589f35fcf73db3ac79514965934da1097 and its parent add plumbing for telemetry messages directly from devices (no demodulator), but it's not at all applicable to non-telemetry.

[quentinmit]

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.

[kpreid]

@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.

[quentinmit]

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).