Development brainstorming

Audio Processing and Routing

• ffmpeg - simple and powerful, tons of formats, does streaming very well. Not rich in features for streaming. No audio routing as such. Can accept input from JACK, but not send to JACK. Which is a real shame.
• JACK - Insanely powerful for routing and well-supported by a whole host of applications, no network support on its own
• NetJACK (version 1- version 2 needs multicast etc) - Not well maintained but useful, supports CELT so can be run low-latency and with packet loss/bit error concealment
• VLC - Like ffmpeg, pretty insanely powerful from a formats and streaming perspective. Can also do JACK input and output, which is nice. Bit of a pain to configure. Less formats and codecs supported- no CELT, for instance.
• GStreamer - Not so actively developed, very flexible but not as huge an amount of format or codec support, streaming less well tested
• jack_meter - Command-line dB meter, plugs into any JACK port, provides a running output of dB values in an easily-parsed format (with one flag, draws a meter with another flag)
• jack_capture - Writes audio to a file in real-time
• rotter - JACK program for logging audio for radio, intended for output logging

Configuration

• Everything in a WebUI would be nice, but entails quite a lot of supporting code to make said WebUIs.
• YAML files aren't too hideous
• Command-line options are good for some stuff, but config files/a DB stored config (with DB settings in a config file) are best.
• Being clever, MongoDB might allow for shared configuration between client and server, which would be very handy. Configure everything on the server, have the configuration pulled down by clients upon connection prior to setting up the audio link, and away you go.
• Links from client to server should be server-controlled in terms of run-state and should be monitored on the server - the client, however, should be fed monitoring information for display.
• Assume the worst in terms of defaults.
• Tight integration with system services for on-system-boot automatic setup and recovery and easy control/setup.

Capabilities

• Ability to have multiple streams from contributor[s] to an endpoint, with switching on the endpoint either manually controlled (webui or some form of API running on said webui) or determined automatically (silence-based, fallback).
• Ability to do two-way links with fairly arbitrary channel counts each way.
• Ability to detect link failure (based on program feedback, silence or other parameters tbd) and switch to another working link
• Ability to maintain a local audio source and treat it as a source
• Automatic (not by default) logging and recording of audio data to disk on contributors and endpoint