Would you like to have an integrated Mumble client in FGFS?

[adrian]

I'm working on a Mumble standalone library. Once ready, that could easily translate into an integrated Flighgear client, replacing Asterisk with murmur on the server side. Frequency tuning would be linked with the radios of course.
I'd like some feedback on this.

[ludomotico]

Why does FG need this? As a user, I don't care if I'm using mumble or fgcom. As a server administrator, I find asterisk a pain in the ass to configure, but once configured it just work flawlessly. Which are the advantages of mumble over fgcom? Does murmur support frequencies and range?

In any case, thank you very much for your work. Murmur seems much easier to configure than Asterisk, and in this case enabling an ad-hoc server during some events may be easier.

[Hooray]

In any case, thank you very much for your work. Murmur seems much easier to configure than Asterisk, and in this case enabling an ad-hoc server during some events may be easier.

At first, I only had to google mumble (not being into gaming) - and now I also need to google Murmur next, is that some fancy open source project of your's ludomotico ?

[ludomotico]

No, I'm not involved in mumble. Mumble is the client (equivalent to fgcom in current multiplayer comms) and Murmur is the server (equivalent to asterisk in current MP deployment)

Some of the FlightGear communities use mumble+murmur for multiplayer communications or just chatting about flightgear. As far as I know, Spanish and German speaking communities are more into mumble than into fgcom. I really prefer fgcom/asterisk due to its support for frequencies but if mumble/murmur is going to support frequencies, hey, getting rid of configuring asterisk is a relief!

[adrian]

Which are the advantages of mumble over fgcom?

I don't know, hence the poll. In any case, FGCom would still support Asterisk, it would just get another voip option for Mumble.

Does murmur support frequencies and range?

No, that has to be done on Flightgear's side. Murmur does support temporary channels that are created on request and disappear once no user is inside. Mumble has encryption both for voice and control channel, which adds a bit of CPU overhead. Murmur is not as extensible as Asterisk and supports fewer voice codecs, but has built-in support for Opus, something Asterisk is missing (I think there is a 3rd party app for that). There is also another server for the Mumble protocol, called uMurmur, written in C. It's intended to run on very low resource machines, like routers. I'm using uMurmur for my purposes. Configuration is very simple server-side, and all the work has to be done in the code on the client side. Anyway, work is underway, and the client library won't support anything else but Opus.
Frequencies would be implemented automatically in FGCom just like for Asterisk, except without the server configuration part. Range would be different from the current FGCom version since it would use realistic radio code which takes into account mountains and other terrain.

[Ross]

Yes, I think this would be a great idea.
Yes, FGcom is a great project.
I know nothing about making servers for Mumble, but I do know about using it.
Assuming this would replace fgcom in some cases here are pros and cons.

Pros
Mumble is GNU GPL, therefor you can make servers for free, unlike fgcom where you cannot make frequencys. (Easily)
FGcom doesn't have all the frequencys for airports, and also has unrealistic radio range. (My FGCOM Schiphol forum post)
Easy to use.
Easy to change between channels (frequencys in this case)

Cons

Code (): Select all

Lots

of effort setting server up.
Not as realistic. (no frequency to insert)

Sorry for long post
Kind Regards
Ross

[adrian]

Mumble is GNU GPL,

No, it's BSD licensed. Still free software license.

therefor you can make servers for free, unlike fgcom where you cannot make frequencys. (Easily)

Pardon?

Cons

Code (): Select all

Lots

of effort setting server up.

I just said the server setup is way more simple for murmur vs Asterisk.

Not as realistic. (no frequency to insert)

Erm, you must be talking about the normal Mumble client? I'm talking about integrating a Mumble library into Flightgear, thus frequency support.

[Johan G]

As I see it now, and if FGCom servers will be updated to be compatible with both FGCom 3.0 and older clients, FGCom will be all ok, except for two things: unrealistic radio coverage and, much more importantly, the extremely unrealistic fixed set of radio frequencies all coupled with the range to a fixed position.

That last thing, practically only having ATS frequencies (ATS as in ATC, ATIS etc), is something I have disliked for a loong time. If you can get rid of that limitation and have mumble not use any bandwidth for a tuned channel while not spoken on, I would say you will have something great coming up.

Something I sometimes daydream about is having a 121.5 MHz and/or 243 MHz guard frequency tuned in on one radio, having one VHF and one UHF radio with separate PTT:s or why not, on transoceanic flights, a HF or satcom radio.

One of the things I do for fun is interception, and as far as possible by the book (see wiki article). Three of the things missing is getting intercept vectors over UHF or data link, having a transponder to turn from mode 3A or 3C to mode 2* in order to not set off an TCAS alert and announcing the intercept on 121.5 MHz before switching over to another frequency, usually an ATC frequency I guess.

* These days from mode 3A, 3C or S to mode 4 or 5 I guess.

[KL-666]

The answer is quite simple i think. A sim tries to simulate, so freq entry should be possible from the cockpit if the developer allows for it. There is also the issue of distance. Frequencies tend to get out of reach after 10s or 100s of miles. If these requirements are met, whatever technology is behind it does not matter.

As far as i have seen mumble, it is just some chat program. We might as well go on a group call on skype (with infinite distance).

But if you can make this anywhere near reality in an aircraft, i will surely endorse it.

Kind regards, Vincent

[Kabuki]

Nope, nope, nope. Mumble isn't exactly a tiny application IIRC, and I don't see the point in adding more weight to the download for something that might never be used, especially when it's somewhat redundant.

Mumble works fine as an installed application running on its own. No need to re-invent the wheel that I see...

[adrian]

Thanks for the feedback, saves me a lot of useless work.

[Secret_Hamster]

Tbh I think a mumble/murmur based system would be a vast improvement

Asterisk is too fixed, there is no way to do an air2air sensibly or vary ranges. It's all rather fixed.

Murmur would be a first step to a properly "radiogear" library as a plugin. One object would be some level of backward compatibility, but that will be hard. I'd have probably done some more prototyping had it not been for a somewhat hectic life at present. I've got some initial ideas, that I'm happy to share.

[adrian]

Please do. Any feedback, ideas,.. are always welcome. Proper radio range can be done. I'm also thinking about peer to peer voice, to avoid using the official server when unnecessary (intra-flight comms etc.)

[Omega]

First of all, sorry to hijack this topic.

I'm the webmaster of Virtual Air Traffic Organization (vATO) and we are an event-based virtual organization in FG. We currently have decided to use TeamSpeak for our future events instead of FGcom. We've made this choice because we are planning to have controllers manning whole FIRs by providing radar (center) services. So of course distance is one of the features missing from FGcom.
On the other hand, there may not be enough available frequencies, and we may need to split a facility up to many sectors.

Also in the worst case scenario, the FGcom server may be down. So there must be an alternative way to communicate.

So in my opinion, this is something that we could definitely make use of one way or the other.

To avoid extra work, I would say that just a way to switch rooms using radios is enough for now.

Lastly, can you consider also integrating TeamSpeak in FG? I'm sure many communities out there will benefit from that... such as vATO and FGUK.

[adrian]

Teamspeak is not open-source, so it's out of the question.