-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The project currently lives on github: https://github.com/hbeni/fgcom-mumble/
State: It's working!
FGCom-mumble is a plugin for mumble 1.4 which features simulation of a continuous radio frequency spectrum layered above a mumble channel.
It allows ATC and Pilots to use the insim radio stack equipment to communicate via simulated radio transmissions.
There also is a separate java client (RadioGUI) so you can even try it without flightgear.
The current 1.4 test server is mumble://fgcom.hallinger.org/ (statuspage: http://fgcom.hallinger.org)
FGFS-Wiki page: http://wiki.flightgear.org/FGCom-mumble
Latest release: https://github.com/hbeni/fgcom-mumble/releases (nightlies trough GitHub Actions)
Report issues here: https://github.com/hbeni/fgcom-mumble/issues/new/choose
Useful ressources:
- Install video: https://www.youtube.com/watch?v=jTRzfVfkgZE
- Utilizing RadioGUI for testing: https://www.youtube.com/watch?v=boHsPVTSddk
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Old posting for history:
Mubmle lacked the features to support a plugin to enable radio comms for flightgear at the time the thread was started.
Also i was told that fgcom is unmaintained for the time beeing.
The mumble project currently has some plugin framework in the works, that would make this possible [1]; it will be part of the mumble 1.4 release.
In fact, two projects that are very widespread used and serve radio communication teamspeak plugins, ACRE and TFAR (for the MilSim Arma3), are supporting that effort.
The new mumble 1.4 plugin API looks promising.
If that would come to live, we would need something along the line of the following generic architecture:
- Everyone that would participate principially on the radio will join a dedicated mumble host and join a specific channel.
- each mumble client loads a specific fgfs-fgcom plugin.
- that plugin need a very public documented API, so third party software can interact easily with it.
Ideally this API is platform and language agnostic (some mini REST-Service maybe? Or some very simple TCP socket?) so it can be invoked from third party software (eg: ATC-Pie, OpenRadar, fgcom-standalone) easily. - fgfs communicates with this plugin (some arbitary) and provides the following information: position, number of radios in use, frequencies selected, volume of each radio, PTT on each radio pressed. This information is gathered from standard fgfs properties.
- The plugin now does the following things:
- calculates client side, based on that information, which clients it currently can hear (based on simple distance at first, but we may introduce arbitary complexity, like realistic radio wave propagation models there like ACRE does already - maybe even code can be used from their effort)
- Calculate, which clients can be heared, based on the tuned frequencies and distance (and advanced modelling stuff like said above).
- Clients that can be heared this way are unmuted and may be heared this way (his approach will save bandwith as i understand it, as the server will just send data to unmuted clients).
- As soon as some client sends some voice data, the plugin intercepts the audio stream and does this stuff:
- If the user is actively PTTing, the reception is muted (discard received data).
- If he is not, the incoming voice stream is intercepted. Based on signal strength (->see radio wave model) volume of the voice is adjusted and some white noise introduced, to the extent that on the edge of the possible radio distance it is barely hearable and just nearly all white noise (note that this may already be doable with mumbles positional audio feature).
For easy transition we might adjust the current fgcom implementation to detect if such a plugin is loaded and then offering that as an alternate "server" in the dropdown menu. Then fgcom may just send the properties there.
The standalone fgcom may also send the data this way, so openradar/atc-pie does not need to be adjusted (r).
Alternatively the plugin itself may hook up the property tree of the fgfs instance since that is already accessible easily [2] and circumvent fgcom entirely (however openradar etc need to implement that interface too then.).
The Pro's of this approach would be the following:
- All the voice stuff and networking problems are dealt by mumble.
- Server setup is really easy: just install a murmur server and let people connect. No special server side setup required.
- The way the plugin is designed above allows for arbitary 3rd party software to use it for radio simulation; it's not fgfs specific.
- I think it is easy to implement, at least at the level of current fgcom features
- It is easy to debug from a users perspective: If the user knows he can chat trough mumble, he has confidence that radios will work too.
- Voice setup is done with mumble, so the user has full control over his input/output device configuration with advanced features from mumble
- Unlimited frequency support. There are no constraints like now that the selected frequency has to be enabled in asterisk phone book: ANY frequency tuned by two pilots will work without having it to be defined anywhere hardcoded.
What do you think of this approach?
(Please note that sadly my c++ programming skills lack the means to implement most of this that stuff myself).
[1] https://github.com/mumble-voip/mumble/pull/3743
[2] http://wiki.flightgear.org/Property_tre ... perty_tree