Output multicasting?
in General Chat
For several years now I've been writing my own SDR, mainly to experiment with multicasting of I/Q, audio and receiver status streams. For example, audio from my receiver is multicast back out on the LAN as an Internet-standard UDP/RTP (Real-Time Protocol) PCM stream. I've found this a very versatile way to plug together modules in a streaming pipeline, or to feed multiple programs with a single output without any prior configuration. For example, I have an AX.25 packet decoder listening to multicast receive audio streams and in turn multicasting the decoded AX.25 frames so they can be picked up by another program that reports them to the APRS network.
It occurs to me that I could package up the DREAM demodulator as a Linux program that would accept raw multicast I/Q as input and emit the decoded audio as one (or more) separate multicast streams. This is one way I might offload the compute-intensive DRM decoding from the resource-starved Beagle CPU to a larger computer with more CPU cycles.
How hard would it be to do a plug-in for KiwiSDR to multicast its audio output? I'm willing to do the work if I can get a general idea of how feasible it is likely to be before I jump into the source code. Thanks!
It occurs to me that I could package up the DREAM demodulator as a Linux program that would accept raw multicast I/Q as input and emit the decoded audio as one (or more) separate multicast streams. This is one way I might offload the compute-intensive DRM decoding from the resource-starved Beagle CPU to a larger computer with more CPU cycles.
How hard would it be to do a plug-in for KiwiSDR to multicast its audio output? I'm willing to do the work if I can get a general idea of how feasible it is likely to be before I jump into the source code. Thanks!
Comments
kiwisdr.com is a VPS hosted at Linode which, in addition to hosting the website, hosts the Kiwi proxy and TDoA services. The TDoA engine uses Octave and is too compute intensive to run on the Beagle. So the TDoA extension knows how to send it a list of sampling Kiwis and then displays the maps it receives.
Re my DRM program, I would probably have it accept I/Q PCM and multicast the demodulated but still compressed audio frames on another group. The audio codecs would best be added to my "monitor" program that actually plays audio on a sound device. Right now it handles PCM and Opus, but it shouldn't be hard to add all the codecs in ffmpeg or whatever.
The hard part will probably be writing the metadata routines for the KiwiSDR. Audio is multicast as bare linear PCM to one multicast address/group while I multicast my own metadata format to another address/group. My format has been fairly stable, so I should probably write it up. It uses a series of type-length-value tuples to encode all sorts of stuff, e.g., timestamp, receive center frequency, mode, filter settings, packet and sample counts, etc. It can also be used to convey commands (tuning, mode, IF filter settings) to the receiver.