Talk:Integrating FGCom

Status 08/2013

FGCom has been integrated into FlightGear on 19 Aug 2013, he won't be part of FG 2.12.0.

fg/flightgear and fg/fgdata repos are fully modified and FGCom can be used from now.

F-JJTH (talk) 15:16, 19 August 2013 (UTC) Clément de l'Hamaide

Status 07/2013

I've now implemented all what I wanted about FGCom. Now FGCom built-in is stable and fully working. As stated with James, it's planned to add the feature once 2.12 branch is created. Also Vivian will add the new dialog http://i83.servimg.com/u/f83/16/09/76/33/captur13.png in fgdata at same time. — Clement de l'Hamaide

Also see: https://forum.flightgear.org/viewtopic.php?p=188214#p188214

The problem is the underlying audio-layers (OpenAL, and whatever it is implemented on top of, which can be many things, especially on Linux), don't necessarily support either selecting the device (on Mac), or multiple devices open from the same application concurrently. All the issues are probably solvable with time and patience, but it's a tough problem since there is no good, free, cross-platform audio library out there which does what we need; PortAudio is not actively maintained, for example, and OpenAL itself has implementation issues in different places.

If you'd be interested in experimenting in this area, please do so - in theory you can open up a secondary OpenAL context, and the FGFX layer knows whether a sound is radio, environment or so on.

Integrated Text To Speech (TTS)

The audio -- in particular the text-to-speech -- is definitely in need of improvement. I'm thinking that's where the emphasis should be, rather than spending too much effort on textual presentations. — John Denker

ideally ATIS and other services would *also* be delivered via FGCom, which would clean up a whole bunch of things. — James Turner

If ATIS also used the that system I think we'd be home. — Anders Gidenstam

text to speech. AFAICT the status is: 1) The existing home-brew TTS system (involving ATC/default.vce and ATC/default.wav) is very limited. It does not claim to handle the general case. It does not even have enough vocabulary to handle an ICAO standard ATIS (with perhaps verrry rare exeptions). It only knows the names of a few airports. 2) There is a documented interface to the Festival TTS system. Alas, the preponderance of the evidence indicates this has not worked in several years. AFAICT all reports of working TTS refer to the home-brew system (item 1 above). I have no opinion on _how_ to implement TTS, whether home-brew, Festival, or other. However, _some_ sort of robust TTS would be extremely valuable. (If this is not obvious, I would be happy to discuss _why_ it is valuable.) — John Denker

I would like to point you to a text-to-speech library developed by the Carnegie Mellon University: Flite (festival-lite, see http://www.speech.cs.cmu.edu/flite/). It can be embedded in existing code quite simply, requires no additional dependencies, is thread-safe and distributed under an X11-like license which should (please correct me if I'm wrong) be compatible with the GPL... — Mirko Stanisak

Looks very interesting - have you used it yourself? Would be good to know how complete, actively maintained and so on it is. I'd sooner ship 2mb of code than 30mb of wav files, if it opens the door to arbitrary, ideally Nasal-based, ATC/ATIS/etc. Festival has always been too scary to consider embedding. — James Turner

The voice quality of flite is a) good enough for ATIS/AWOS (which in real life are often synthesized and artificial-sounding), and b) better than anything that is likely to be achieved anytime soon using the current code that pastes together snippets, and c) infinitely better than what is in the git repo at the moment, which is no ATIS at all. Also: The cpu workload of flite is pleasantly small. On my machine it takes something like 60 milliseconds to render a typical ATIS message. Furthermore -- if properly implemented -- this could be done in a separate thread, so that in a modern multi-cpu machine no time at all would be taken away from the main simulation. — John Denker

Melchior wrote some nice enhancements to the tutorial system that might be of use here. Specifically, a given piece of message text that is to be displayed on the screen and sent to the TTS engine can contain alternative phrases for the TTS engine, so that the user sees "Runway 36" and the TTS engine plays "Runway three six" rather than "runway thirty six". As Robert indicates, one of the big challenges for using audio for clearances etc. is getting the pilot's input into the system. A menu system seems the most appropriate way forward. With a bit of effort, I think it could integrate into an automated ATC service that recognizes standard phrases, delivers clearances etc. Such a service should be able to run as a standalone app connected to the MP system so everyone can benefit even when there is no active human ATC. Of course, we already have automated ATC within the sim, but IIRC it doesn't integrate with the TTS. — Stuart Buchanan

FGCom

Usability was the main reason for making terrasync be available as in-process option, and I'm strongly considering doing the same thing for fgcom, although that has a few extra complications. — James Turner

I can't imagine there's a large use case of people who really want to build fgcom standalone, but haven't already built fgfs from source. I do absolutely agree there are reasons to keep a separate /binary/, to run on a separate machines or similar, as an option (as we do for terrasync), but again for a large number of users the easiest solution would be an 'in process' one in terms of setup, configuration - and the easiest way to achieve that is to make the (tiny) amount of fgcom code live in the fgfs source tree. — James Turner

my intention is to move fgcom into the flightgear code repository, and to make it a library function that can be compiled standalone or into fgfs[.exe]. This will simplify the setup, and also mean everyone has access to FGCom. It would also then be possible, to add some feature, that when MultiPlayer is enabled, we automatically tune people to listen in to 'nearby' ATC - maybe on some special advertisement frequency. Think ATIS but with a message saying 'voice ATC is available in this area - please tune your com radio to xxx.xx to participate'. I think being able to listen-in, without participating, would help new users get the idea of voice ATC, without feeling the must join in. But I may be wrong about that! Since we have the XMLHTTPRequest code working now, it's easy to retrieve a list of FGCOM servers dynamically, or even a list of active ATCs - with arbitrary fields such as locale (lat / lon) and frequency, and offer a dialog box to tune to them. You can imagine a web service that lets ATCs register as being online/offline at a particular facility. — James Turner

I'm absolutely in favour of splitting things up - Mathias and Martin know this from LT. Yet, I did not see any contradiction with integrating terrasync. I would like more subsystems being converted into separate libraries and being capable of running them outside FlightGear (which, I agree, is great for any advanced user - especially those with CAE-like setups), but still have the option to also run the same subsystems all inside a single FG (which does have advantages for other kinds of users). With a proper and flexible interface (HLA could be the solution here) both is possible. When we have that standard interface installed, we can use the new library with it (while the left-over bits of terrasync(.exe)'s command-line/UDP code might die and be replaced by some generic loader). — ThorstenB

IAXClient / Asterix is working okay for us. I wish the Iaxclient code was better maintained, and if there was an actively maintained SIP library we could use, it would certainly be appealing, but the options are surprisingly limited. In terms of the code layout, some people want the option of a standalone application for fgcom, but just like TerraSync, 98% of people want an integrated function that 'just works' when they choose a GUI checkbox. Making the current fgcom code work as a thread inside fgfs isn't especially hard, I am happy to offer advice on it, and keeping this an #ifdef / CMake flag so it can be a standalone process is also pretty easy. (I'd vote for moving the code into FlightGear, SimGear doesn't really make sense for this) The big problem for me is not iaxclient, but the audio backend it uses. We're mostly using the OpenAL backend, but on Mac that works quite badly (can't select different output device for FGCom vs normal sim audio) I'd prefer to use PortAudio on Mac (a newer version that the one included with fgcom!), but I am (very) worried about introducing audio problems with different PortAudio backends on Linux. (I have looked at writing a custom CoreAudio backend for iaxclient for Mac, but I didn't find the enthusiasm for that yet) Anyone who wants to work on any parts of this, I'm happy to offer guidance or sample code or anything else to help! — James Turner