AfV volumes

[Jonas Eberle]

I am using Linux with xPilot/Swift/VectorAudio (not sure if that makes a difference or if all audio algorithms are the same in any software). I must also say I have not researched if I can tweak audio output on my side.

 

I think AfV mostly sounds great and really realistic.

But don't you agree that some pilots/controllers are just way too loud?

 

There is something about that "too loud" (clipping), that does not sound realistic for an analog RF transmission. It can even be hurting to the ears and is not pleasant.

For analog hardware going in "too hot" should "warm up" the audio by spilling the over-saturated frequencies into adjacent frequency bands. But that is hard to do in digital AFAIK.

 

I am a hobbyist musician and as a rather easy measure against these very hard spikes I would recommend a "simple" wide-band compressor with short attack, threshold of 70% and ratio of 4:1. To my knowledge this is widely available in audio libraries. This would dampen the hard spikes while still preserving some dynamic.

Edited August 19, 2022 at 07:13 AM by Jonas Eberle
English syntax

[Alistair Thomson]

It depends, I think, on where the distortion occurs. From the reports I've read about this, I'm guessing that the audio leaves the sender's computer electronics clean and gets digitized by AfV for transmission. If there is clipping there, most of the dynamics are lost and a graph of digital level against the count of samples at that level will show lots of fullscale values.

If the original signal arrives clean, then AfV may somehow be mis-decoding and producing lots of fullscale values before passing the signal to the computer's DAC.

That will sound dreadful, loud, distorted and maybe even unintelligible. The square-wave nature of the signal will be full of high harmonics and filtering these out would probably help. I'm not sure that adding compression will help! Or is your suggestion to use expansion with a compander? That may not work if the clipping is severe because the dynamics won't be there so can't be spread.

[Jonas Eberle]

Yes, I think you are right. Needs more investigation where that clipping is produced.

[Daniel Neugebauer]

On 7/10/2022 at 3:46 PM, Alistair Thomson said:

I'm not sure that adding compression will help! Or is your suggestion to use expansion with a compander? That may not work if the clipping is severe because the dynamics won't be there so can't be spread.

It may also be some issue with my local system (although I only have it when flying online) but sending the audio output into an audio effects chain of a limiter followed by a compressor made VATSIM audio bearable again. It's set up in PulseAudio (Linux audio system) following https://gist.github.com/lightrush/4fc5b36e01db8fae534b0ea6c16e347f

Before I added that chain, I heard around 20% with an excessively loud volume. The remaining 80% had "normal" volume (or maybe they were way too quiet?!). It's true that clipping can't be corrected on the receiver's end but at least you are able to hear all stations at a normalized volume and are no longer at risk of damaging your hearing. It also seems like loud stations are not always clipping, so maybe it's not actually a problem with the sender's microphone but actually an issue in AFV when receiving those signals?

BTW, does anybody know how audio levels in aviation comms are handled in the real world? I would be surprised if there wasn't some sort of volume normalization built into the receivers. However, AFV and pilot clients obviously don't support that yet.

[Jonas Eberle]

Thank you for following up @Daniel Neugebauer.

 

I also had some sessions with the digital post-processing disabled:

 

xPilot:

VectorAudio:

 

I can also confirm that clipping does not occur often. I guess in those rare cases it is really a misconfigured microphone set to too high levels.

What's noticable are really the different loudness levels (with some few excessively louder than most) among stations.

 

I am not sure I am able to understand that processing chain (from the gist https://gist.github.com/lightrush/4fc5b36e01db8fae534b0ea6c16e347f) correctly: Is it really limiter into compressor? Using the compressor before the limiter should preserve more dynamics.

 

If there is interest, we could gather raw audio and try with different processing chains.

The question is where we could upstream those improvements.

 

Maybe it should rather be done at the voice server level?

 

Nota bene: It seems that AfV code bases have diverged. That's not beneficial for topics like this if we would want to improve the situation for all:

• Windows AfV is closed source (?)
• xPilot uses https://github.com/xpilot-project/afv-native (probably?)
• VectorAudio uses a fork https://github.com/pierr3/afv-native/
• Swift seems to use https://github.com/swift-project/pilotclient/blob/develop/0.12/src/blackcore/afv/clients/afvclient.h