Hello,
[Note for those worried about this as other worries were expressed in other threads: this is not a feature problem but a network/CPU load optimisation issue. As far as I am concerned, the radio feature works fine as things are, though the concern will be more serious with old machines as more load will mean slow-down.]
After a few tests and a version history search, I suspect the problem is neither ATC-pie nor OpenRadar, nor the FGCom server alone, and rather involves new FGCom 3.4 client released in January before which the problem does not occur.
Taking ATC-pie commits for the sake of argument, here is the relevant part of the project chronology:
(a)
commit e51c0 (Jan. 25)
Uses older FGCom 3.0 client and older FGCom server at the time, maintained by Clément
(b)
commit 85325 (later same day)
FGCom client version change to just released stable version 3.4
(c)
reported problem (Feb. 18)
CaptB and henrikp
report that FGCom is not working on Windows while all Linux users have it working fine
(d)
commit 6235d (Feb. 19)
Thanks to Clément who found what the problem was, Wolfram and I could solve the problem: the new FGCom server was expecting a new SILENCE_THD value in every packet which was not documented and for some reason defaulting to 0 on Windows only
(e)
server change (April)
A new FGCom server takes over, maintained by Kévin Seroux.
Running ATC-pie on the listed commits with current FGCom server clearly shows:
(a) less than 1% of CPU load for either echo test or regular frequency
(b) less than 1% of CPU load for echo test and a 1-core 100% load for regular frequency (like what vector here is saying)
(d) same as (b)
So one question is: was the problem ever noticed between late Feb. and late March, i.e. when the new client and old server combination would be in place? If not, the current server might be part of the problem, but in any case the 3.4 client is.
To be honest I do not know what exactly could be happening technically as my job is pretty much limited to encapsulating a client instance under ATC-pie, and Wolfram would probably say the same for O-R. At (d), Clément explained to me that the 0 value for SILENCE_THD was in fact muting the microphone, which is why others could not hear when ATC used Windows. I have tried placing the 0 value back with latest config to see if it inflicted on the packet load, but it did not.
Funny the problem does not happen with echo test. For comparison, here are the differences in the command line options:
- for
echo test: --server --port --callsign --frequency
- for
regular freq: --server --port --callsign --airport