601
edits
FGCom-mumble: Difference between revisions
Jump to navigation
Jump to search
Idea draft for FGFS integration
mNo edit summary |
(Idea draft for FGFS integration) |
||
| Line 151: | Line 151: | ||
FGCom-mumble_radioGUI-0.6.0.png|RadiGUI 0.6.0 | FGCom-mumble_radioGUI-0.6.0.png|RadiGUI 0.6.0 | ||
</gallery> | </gallery> | ||
== Idea to integrate into FGFS == | |||
Using [https://github.com/mumble-voip/libmumble libmumble], a standalone mumble c++17 library, we could integrate FGCom-mumble directly into FlightGear. This way, FGFS would talk "mumble" to a mumble server and the plugins functions would be integrated into the core. For pilots, a simple "click" to connect in the multiplayer would be enough to participate, while having all the advanced features of fgcom-mumble available (like custom NDBs, radio stations; as well as the possibility for other clients (ATC!) to participate easily on the radio spectrum). | |||
libmubmble is not yet API-stable, but there was already a [https://github.com/mumble-voip/libmumble/issues/18 first dicussion] about feasability and basic mechanics: | |||
* From FGCom-mumbles side, we need to integrate the data structures into the core. So radios need to be registered, etc. This should not be too hard | |||
** we probably just need to not run the UPD-Server but send the needed data directly into the decoding function of it. At a later stage, we might better integrate that part, but for a first working solution, just creatig a FCGOM-mumble UDP-Packet string in FGFS and sending it periodically (or already on-demand?) into the udp-servers decoder function should be enough - it just creates some CPU overhead which should not be too bad and will establish the needed local data structure. | |||
** Note, that we cannot rely on the mpservers data structures (even if there is radio data), because in FGCom-mumble potential other clients are also participating (like radio-playback bots for ATIS etc!). So we really need to use mumbles plugin messages. | |||
* Basicly the libmumble will run its own threads for networking. Upon receiving mumble audio or mumble-plugin data, callback functions would be called from the lib: | |||
** Incoming audio data need to be processed by the fgcom-mumble plugin functions, and then the result handed over into fgfs audio out handling. | |||
** Incoming plugin data needs to be fed into the fgcom-mumble internal remote data struct (just hand the data into the existing data parser). | |||
* Pressing the already existing fgfs PTT button | |||
** would need to send plugin data to mumble, to inform other clients. This is currently done by calling a mumble client function, but that is surely not available from libmubmble. It would probably be enough, if fgfs core supplied an implemention that calls the appropriate libmumble function and hands over the data. | |||
** also, the audio data needs to be fetched from the mic, and then handed over to libmumbles audio encoding and sending routine. This probably can somewhat be partly copied from the legacy fgcom implementation. | |||
* Questions regarding fgfs currently are: | |||
** how to exactly the integration on fgfs side works. That needs peeks on fgcoms code as well as some discussion at the mailing list. | |||
** how to integrate the libmubmle code into the fgfs build chain (its cmake). | |||
*** legally: libmubmle has a [https://github.com/mumble-voip/libmumble/blob/master/LICENSE BSD 3-clause] licence, is that compatible? | |||
*** And what about libmubmles dependencies, like OpenSSL? | |||
*** technically, how to include that all into the existing build system? | |||