On 22 May 2013, at 12:16, Clement de l'Hamaide <clemaez@hotmail.fr> wrote:

I'm expecting opinion, comments, contributions and even join to this effort. I can't do all this alone because I haven't enough C++ skills (integrate an IAX library in SimGear is impossible for me). I think we need 1 or 2 person who works on the SG/FG side and 1 or 2 on FGCom side. I'm ready to work on the FGCom side (rewrite) with help.

Thanks for the good summary :)

I agree with most of what you said, especially that 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!

Regards,
James