Replace rtl_fm with UDP or REST implementation

[wizardishungry]

rtl_udp or rtl_fm_python allow us to control an rtl_fm process over a UDP or TCP control socket respectively. Leaning towards the UDP implementation as it should be simpler.

Advantages

• Easily allows multi dongle setups; right now rtl_fm has statically allocated structures that need to be converted to be per device. I'm not in the business of refactoring rtl_fm.
• removes threading code; we'll just select on a file handle streaming PCM.
• Additional tuning parameters:
  • controllable with CV: gain, squelch, decoding mode (FM,AM,USB,LSB)
  • controllable with panel control: auto gain enable
  • will require rtl_fm restart (use context menu): dongle index
• Removes hacked rtl_fm code from repository; will be included as a submodule & packaged with zip.
• potentially add other fm decoding modules to the mix
  • redsea - Radio Data Service display
  • darc2json - more radio data
  • stereodemux - STEREO AUDIO
• Moves all that I/O out of Rack
• rtl_fm crashes won't crash Rack
• Allows BSD license for entire module and maintains my copyright, so I can distribute this module linked against my proprietary code for the Pulsum Quadratum module pack.
• Circumvents GPL licensing issues for adding panel graphics copyrighted by me. I will use a license similar to the Fundamental SVGs. See VCVRack/Rack#854
• Fixes static linking issue on Linux #26

Disadvantages

• Neither implementation has a network transport for PCM data, so we won't be able to add an option to stream from a remote dongle.
• Potential increase in latency for both PCM data and tuning. Tuning granularity over time is bad right now; you may only tune ~10 times a second. I believe I also modified the rtl_fm sources to not clear the audio buffer after a tuning event. We may need to include a patch to the rtl_fm implementation to replicate this behavior.

[wizardishungry]

@davephillips @dizzisound: feedback appreciated

[davephillips]

Hi Jon ! The proposed changes look good, I'd like to see the expanded capabilities. However, I am concerned about latency and granularity so I'll be watching/testing those aspects for any degraded performance. The module works well for me now but of course I'm always interested in your improvements. :)

[wizardishungry]

• Granularity – Existing rtl_fm code runs in a bunch of pthreads with a whole mess of synchronization between them. This is from memory but: tuning uses rtlsdr_set_center_freq which blocks for quite a while on each call. I played around with spawning a new thread to make a tuning call, but it looks like there's a a bit of back and forth between librtlsdr and the dongle for each tuning operation - i.e. it isn't just a single message "set dongle frequency". So having multiple rtlsdr_set_center_freq calls running breaks the instance. In short, I don't think this is going to make things much worse, as major limited factor for tuning granularity is librtlsdr chatting with USB not context switching. (Also just came up with #39 to try to improve our tuning performance in existing architecture. )

• Latency – there's two layers of buffering going on between the dongle and rack. I'm concerned that right now we're getting further behind on outputting the buffer than we need to be (and never catching up). What about using a popen pipe instead of the second shared memory buffer? Perhaps we could get better performance by seeking to the end of the popened stream on start, attempting to read into a buffer / outputting 0.f until we see data. Dropping a few samples at the start of operation is better than being thousands of samples behind the radio for the duration of operation.