VATSIM new audio codec? Any release date info, donation?

[Tomasz Gawronski 1413424]

Pilots,

The were a lot of discussions about poor VATSIM audio quality in the past.

Anyway I've found an info on the VATSIM website from the last year , which states as follows:

New Voice Codec

 

Voice quality on VATSIM has long been the subject of much discussion on our network, with the compatibility of older pilot clients being a barrier to upgrading to a new voice codec which would improve voice quality for our pilots and controllers.

 

At Connexion 2017, Kieran Hardern, who sits on the VATSIM Board of Governors, made an announcement that VATSIM has a team actively working on the implementation of a new voice codec. A number of tests of specific codecs have already been completed and VATSIM is committed to make this happen. As with any voluntary project, we won't be putting an estimated time of release out on this but hope this announcement is of interest to our members who have been eagerly waiting for this upgrade.

 

Source: https://www.vatsim.net/news/new-voice-codec-voice-unicom

 

It was almost year ago.

 

Is there any update on this subject?

I understand that this is a voluntary project so maybe there is some donation possible?

 

I'm ready to donate the developers to get clear audio quality. I'll bet that the others will help too.

 

What do you think?

[Steven Perry]

I think the date format is YYYY-MM-DD... so 2017-08-04 is more like half a year ago. Though, either way, the legacy pilot client issue still remains.

 

Swift is to be the pilot client that offers a solution for a wide variety of simulators. I think the codec will, out of necessity, follow the release of Swift. See the recently active thread about its progress.

[Andrea Mazzoni]

I would share with you some informations. I'm a C1 controller, today I planned a flight during an event of VATPRC from ZBAA to ZGGG but it was impossible understand the ATC, so I decided to disconnect. Why? Because the current CODEC, the MELP, maybe could be appropriate if you want simulate an HF frequency, but not a VHF frequency. A lot of users doesn't understand what I tell to the other pilots due to this outdated codec, TOTALLY INAPPROPRIATE for this network. First Priority of BOG should be to release immediately a better codec, because if I want fly in some areas that I never explored, I want understand all trasmission between me and all ATC. A better CODEC can help ATC and Pilots for a better communications. Is not a question about if you have a microphone low-cost or one of the most expensive microphones in the world, because I have one of the most economic microphones and when I use Skype, Teamspeak3 or Discord, the audio quality is excellent. Every time when I find an ATC on VATSIM, I think that our ATC are the Daft Punk! (a electronic music duo)

Sincerly, I hope that this problem will be solved as soon as possible.

[Matthew Cianfarani]

The VATSIM Board of Governors appointed four new members a few weeks ago, three of whom are working in Technical roles.

An improvement in the area of a CODEC has been committed to by the Board and is absolutely being worked on. I am not able to offer (Nor would it be my place to do so) any timelines.

 

However, we hear your feedback and please rest [Mod - Happy Thoughts]ured that this is on the list.

[Robert Bressert]

Thanks Matt! That's encouraging.

[Nicholas Cavacini]

Andrea, I hear that argument all the time. However, every time it comes up, it turns out to not be a codec issue at all. It is almost always at the end of one of the users, whether pilot or ATC. Most of the time it is users attempting to use a low quality microphone/speakers, or they have an improper setup. I have not once ran into an issue where the Codec was the issue.

 

I would recommend ticking the box in whatever client that you use (most support it) that says something like realistic distortion or VHF distortion. This makes the audio sound much more realistic.

[Antony Radley]

Andrea, I hear that argument all the time. However, every time it comes up, it turns out to not be a codec issue at all. It is almost always at the end of one of the users, whether pilot or ATC. Most of the time it is users attempting to use a low quality microphone/speakers, or they have an improper setup. I have not once ran into an issue where the Codec was the issue.

 

I would recommend ticking the box in whatever client that you use (most support it) that says something like realistic distortion or VHF distortion. This makes the audio sound much more realistic.

 

The codec is an issue stop pretending it isn’t. It’s 2018 now. Let’s not use 1990s technology.

[Nicholas Cavacini]

I'm not saying the concern is not valid and is in the process of being worked on, however having flown IRL, the quality of VHF is about the same as our current voice systems with Realistic Distortion enabled.

[Daniel Hawton]

I'm not saying the concern is not valid and is in the process of being worked on, however having flown IRL, the quality of VHF is about the same as our current voice systems with Realistic Distortion enabled.

 

If not better.

 

As has been indicated several times, the primary issue with the codec is the built in latency, not the quality.

[Johnny Coughlan]

Andrea, I hear that argument all the time. However, every time it comes up, it turns out to not be a codec issue at all. It is almost always at the end of one of the users, whether pilot or ATC. Most of the time it is users attempting to use a low quality microphone/speakers, or they have an improper setup. I have not once ran into an issue where the Codec was the issue.

 

I would recommend ticking the box in whatever client that you use (most support it) that says something like realistic distortion or VHF distortion. This makes the audio sound much more realistic.

 

Why is it people like you and a staff member at that still bury their head in the sand on this topic and continue to tow the party line of "it's not us, it's you", when it come to voice issues.

 

Yes, sometimes it is but not ALL the time.

 

Change needs to happen with the voice architecture, we were promised it, if it's being discussed behind closed doors fine, us mere general members would just appreciate something more solid like a timeline, project update, roadmap, something, all we get is a PR piece that's it's being handled every time it comes up.

 

Rant over.

[Dace Nicmane]

I planned a flight during an event of VATPRC from ZBAA to ZGGG but it was impossible understand the ATC

Just a thought, the Chinese accent can be really difficult for a European to understand, plus they have the metric system and maybe some other differences in phraseology, I've flown there a couple of times and it isn't easy I promise. And some controllers are worse than others because of their setup, I don't know how many times I asked to say again on that event flight but some of them decided to text me every instruction along with voice for which I was grateful.

[Daniel Hawton]

Andrea, I hear that argument all the time. However, every time it comes up, it turns out to not be a codec issue at all. It is almost always at the end of one of the users, whether pilot or ATC. Most of the time it is users attempting to use a low quality microphone/speakers, or they have an improper setup. I have not once ran into an issue where the Codec was the issue.

 

I would recommend ticking the box in whatever client that you use (most support it) that says something like realistic distortion or VHF distortion. This makes the audio sound much more realistic.

 

Why is it people like you and a staff member at that still bury their head in the sand on this topic and continue to tow the party line of "it's not us, it's you", when it come to voice issues.

 

Yes, sometimes it is but not ALL the time.

 

The CODEC is not the problem. The quality of the CODEC is better than RW VHF radio transmission quality. And just like rw, if a pilot has a rubbish headset then they are just as difficult to understand as they are on VATSIM. The issue is not the quality, but rather the latency that is built in to it causing people to step on each other.

 

Change needs to happen with the voice architecture, we were promised it, if it's being discussed behind closed doors fine, us mere general members would just appreciate something more solid like a timeline, project update, roadmap, something, all we get is a PR piece that's it's being handled every time it comes up.

 

New staff members are in place and there was no change over brief... give them time to get their feet under them before making such demands. If you'd like to join in and help, then do so.

[Thimo Koolen]

I don't know about you, but I've spoken to a few real life controllers and pilots and they say real life audio is waaaaaay better. Super clear quality.

 

I did a flight in the USA again after a long time not flying there and I could barely understand the controller at all.

[Steven Perry]

Sim pilots use $3.99 stand microphones placed on the other side of their desk and try to transmit while eating doritos and chugging beer. They calibrate their mics once when they install Vpilot/VRC/Whatever and rarely if ever do so again.

 

Real pilots use a $100+ purpose built aviation headset with a muffed mic placed milimeters from their lips. They calibrate their mics every flight because they can hear themselves on the intercom or on the side tone when transmitting.

 

Since the beginning of voice controlling on the network, the only readability issues I've experienced have been hardware or user related. Ask the unreadable controller or pilot to re-calibrate his mic.

 

Latency is an issue.

 

A possible issue I believe to exist is when pilots/controllers are on multiple frequencies at once. I have observed that when a controller is monitoring a 2nd frequency that the transmissions on the primary frequency are broken (intermittent) when he is simultaneously receiving a transmission on the secondary freq. Has this been discussed yet?

[Daniel Hawton]

I don't know about you, but I've spoken to a few real life controllers and pilots and they say real life audio is waaaaaay better. Super clear quality.

 

I did a flight in the USA again after a long time not flying there and I could barely understand the controller at all.

 

I've been controlling rw for just about 10 years and have been flying for the past few... radios online are most definitely far better audio quality-wise unless you encounter a person using a $3 mic... in which case, no codec will fix that.

[Nick Papandreou]

The codec/latency issue has been discussed in details the last couple of years. It's not a matter of poor quality mics or mic's calibration. It can be a significant factor to the voice quality yes, but it has nothing to do with the 20 years old technology audio codec that needs updating. There are pilots in our VA that sound crystal clear when using teamspeak and the same time you can barely make out what they are saying when speaking on the frequency.

 

Latency is another major issue but i'm not sure if it's related to the codec or not. Ross explained it well in an older post:

 

However, there is a third source of latency which is the buffering done on both the sending and receiving side in order to prevent gaps in the audio stream that can be caused by jitter in the network latency.

 

From what I've learned by talking with the devs that are looking into improving our voice system, it is this third source of latency that is the largest contributor for VATSIM. You said that latency is a problem that cannot be fixed, only slightly improved, but in actuality it can be dramatically improved. The amount of buffering done on both the sending and receiving end was designed to accommodate decades-old networking technology where there was far more jitter in the network latency. This buffering can be reduced now that connections with less jitter in the ping times are the norm. Yes, we will still have some users with high latency in their network connection, and they will still be prone to stepping on others or being stepped on, but those users are the exception rather than the norm these days.

 

It is already announced that a vatsim team is working on a new codec and that means there's acknowledgement the codec needs reworking.

 

Hopefully the upcoming changes will address both the outdated codec and the high latency that's causing pilots and controlers stepping on each other. I agree though, it would be good if we had frequent updates on the subject.

[Magnus Meese]

It pains me to see that people defend the codec we have got.

Yes, many people use their equipment and software wrong.

Yes, many people have poor equipment to begin with.

Yes, simulated radiotelephony on the network is still possible and you can make yourself understood.

 

No, this doesn not justify an ancient codec with an insane buffer delay and terrible quality based on one of the FIRST FLIPPING VOIP-CODECS EVER SEEN ON THE WWW, PUBLISHED BEFORE THE TURN OF THE MILLENNIUM!

 

Yes, it's good that the people on top now has started to talk about it rather than the complete disregard shown in earlier years.

 

No, that definitely does not give me hope that we've gotten anywhere with this before the decade is out.

[Jack Colwill 815386]

I find the quality hit and miss. What I think is really needed is the ability of a controllers transmission to override every pilots transmission. So when the controller pushes his transmitter you only hear him /her. You know how many times, especially during a flying, the controller has to retransmit an i instruction because 10 people just checked in at the same time. This slows down progress and eventually turns an event into a goat show. An atc instruction is more important that an initial check in from a pilot.

[Ross Carlson]

I agree that the controller gets stepped on a lot, but I don't think we need to have controllers be able to override others. I think that particular problem will be solved by reducing the latency. That's what causes people to step on each other (controllers included) way too often.

 

That being said, if we're not able to reduce the latency enough to prevent people from unwittingly stepping on each other all the time, then giving controllers the ability to override would be a good (though unrealistic) change.

[Randy Tyndall 1087023]

Please forgive me for being dense about the codec, latency, and comms in general.

 

I, for one, have been told I have experienced the "latency", but if so that has never taken away from my enjoyment of the network. So, at the moment and without knowing what it "could be", I am perfectly happy with the status quo. However, given that so many people are discussing and recussing this I [Mod - Happy Thoughts]ume it is an issue.

 

Based upon that [Mod - Happy Thoughts]umption, is the latency only a problem with pilot clients or with ATC clients as well? Again, please don't "snark" at me, I don't understand this whole "codec" thing. If just the pilot side and ATC is fine...but getting stepped on by a fault on the pilot side not hearing that ATC is transmitting...then by all means, advances must be made. While clarity seems to be the issue as well, getting "stepped on" seems to be the driving force behind the search for a "codec fix".

 

However, if both Pilot and ATC sides experience latency, does everyone experience latency at all times and to the same degree...because of the codec...and just doesn't realize it until an event sized gathering of pilots and ATC in a regionalized location?

 

Bear with me, I am headed somewhere I [Mod - Happy Thoughts]ure you. If everyone experiences the same degree of latency then exactly how is a new codec with no or at least significantly reduced latency going to fix getting "stepped on"? To be more specific...getting" stepped on" due to latency means someone is already talking but, because of latency, no one knows it yet so they hit PTT and start talking, stepping on the person already talking that they can't hear...yet...correct? That, so it seems, while annoying at any time is only a huge annoyance during events when several people...not hearing somebody already talking...will be keying mikes stepping on everyone else.

 

Fast forward to new codec...big event in progress...comms are crystal clear and at this moment no one is talking and everybody knows that because latency is a thing of the past. Several people key their mike at the same moment to check in, since they hear no one. These pilots do so at the same moment ATC keys their mike to give instruction to someone on the arrival or in the approach. New codec...old codec...somebody is going to get stepped on...

 

The codec cannot predict when a PTT button will be pushed so how is new codec/no latency going to solve "getting stepped on"?

 

Randy

[Robert Shearman Jr]

The minor delay vastly increases the instances in which two people will start talking thinking they have the channel to themselves. However, if person A plans to key up 0.5 seconds after the last readback is completed but is beat to the punch by person B who keys up at 0.25 seconds after it, and person A hears that nearly instantaneously and waits their turn, that's one less instance where someone got stepped on.

 

Maybe I'm not explaining it well, but, trust me that the delay makes the stepping-on problem exponentially worse.

[Ross Carlson]

First, I want to clear up any misconception that the latency is caused by the codec. That's not the case. (The choice of codec does play a part in latency, but it's a small part.) The choice of codec is primarily about voice quality.

 

Latency comes from two places, primarily:

 

The first source of latency is the time it takes for a packet of voice data to get from the person talking to the person listening. That's transport latency. People with slow internet connections, or who are geographically far from the voice server, will have more latency than people with very fast internet connections or who are geographically close to the voice server. Transport latency is what online gamers usually mean when they talk about "ping time" or "server lag". Obviously, there's little we can do about people with slow internet connections. The best we can do to reduce transport latency is ensure our voice servers are hosted in data centers with fast connections to as much of the world as possible.

 

The second source of latency is caused by buffering on both the sending side and the receiving side. When you key up your mic, your client software begins recording your voice immediately, but it doesn't start sending it to the server immediately. It doesn't start sending to the server until a local buffer is full. Let's say this buffer is 500 milliseconds in size. Meaning, it will save up 500 ms worth of your voice before it starts sending anything. The same thing happens on the receiving side. When your client software starts receiving voice data, it doesn't send it to your headset immediately. It also saves the data in a buffer and doesn't start playing it until that buffer is full. Let's say the receive buffer is also 500 ms in size. So you won't hear anything until you have received 500 ms worth of voice data. So that means there is a TOTAL of 1000 ms (1 second) of latency built into the system, just from buffering. (I think the real buffer sizes might actually be 250 ms on each end, but I'm not 100% sure. For the sake of discussion, let's say they are 500 ms on each end to keep the math easy.)

 

So, let's say the two users are on decent, but not awesome internet connections, and each one has a ping time of 100 ms to the server. That means we have a total of 200 ms of transport latency, and 1000 ms of buffering latency, for a total latency of 1200 ms. That's 1.2 seconds. That means that when user A keys his mic, user B will not begin hearing anything for 1.2 seconds.

 

Here's an example of how we get people stepping on each other due to latency ... let's say we have a frequency with one controller and four pilots:

 

1) Controller sends an instruction to pilot A.

2) Pilot A receives and reads back the instruction.

3) Once everyone hears the readback, the frequency is now quiet.

4) Pilots B and C both need to check in, or they both have a request.

5) Once pilots B and C both finish hearing Pilot A read back the controller's instruction, they both wait a few seconds to make sure nobody else is transmitting, and they both key up their mic and start transmitting.

6) Pilot B waits 3.0 seconds before he starts transmitting.

7) Pilot C is slightly more patient, and waits 3.8 seconds before he starts transmitting.

8) Pilot B's transmission starts playing in everyone's ear 4.2 seconds after Pilot A's readback was finished. (The 3.0 seconds that he waited, plus the 1.2 seconds of latency.)

9) Pilot C's transmission starts playing in everyone's ear 5.0 seconds after Pilot A's readback was finished. (The 3.8 seconds that he waited, plus the 1.2 seconds of latency.)

9) For everyone EXCEPT Pilot C, Pilot C has stepped on Pilot B, 0.8 seconds after Pilot B started talking.

10) From Pilot C's perspetive, Pilot B stepped on Pilot C, 0.4 seconds into Pilot C's transmission.

 

The important thing to notice here is that the two pilots don't have to start transmitting at the same time in order to step on each other. They just have to start transmitting within 1.2 seconds (the total latency window) of each other. Therefore, the smaller that window is, the less we'll have people stepping on each other.

 

And it certainly is true that busy events is where this happens most often, but it can happen with just two people on frequency. The more users on the frequency, the greater the chances that two or more people will begin transmitting within the same latency window.

 

Another thing to realize here is that these pilots are not deliberately stepping on each other ... they are both exercising good radio etiquette, in that they are waiting until the frequency is clear before they transmit. I often hear controllers chastising pilots for stepping on other users and I want to yell "They didn't do it on purpose!!" but that would just make things worse. :)

[Jack Colwill 815386]

I agree that the controller gets stepped on a lot, but I don't think we need to have controllers be able to override others. I think that particular problem will be solved by reducing the latency. That's what causes people to step on each other (controllers included) way too often.

 

That being said, if we're not able to reduce the latency enough to prevent people from unwittingly stepping on each other all the time, then giving controllers the ability to override would be a good (though unrealistic) change.

Hi Ross. This is just my opinion so I guess take it as that. But I don't think it's latency. If 5 people push their PTT at the same time latency won't make a difference. During a flying, let's say a busy FNO for example, there are controllers that have probably 3 to 10 times more traffic in their sector than a real life controller has. So the odds of stepping on someone's transmission is way more likely. During regular operations there is usually no problem but when I see an approach controller have 10-20 planes on his frequency that's way too much. Sure you can alleviate the problem by getting more controllers but that's another issue all together. But when an approach controller for example wants to turn a plane on to the intercept course for an ILS and the plane is 2.5 miles from the LOC and you have 5 or so people trying to talk at once, more than likely that plane just blew through the LOC before the controller manages to get his instruction to intercept the LOC. Now if there was a system in place to override all transmissions when the controller hits his PTT the problem is now solved. Not to mention how many more transmissions does that approach controller for now have to issue to get that plane that went through the LOC back on the LOC. Just a thought. I've just seen it too many times from a pilot's side and controllers side of this happening.

[Jack Colwill 815386]

Hi again Ross. Just finished reading your explanation of the latency. Thanks for that. Makes things a bit more comprehensive. My solution to the problem, but not necessarily doable would be this. Controller always had precedence on transmissions. After that, the first one to hit PTT (or in this case the first one that the server recognizes) gets precedence. Probably easier than it sounds to actually make it happen.

[Ross Carlson]

My solution to the problem, but not necessarily doable would be this. Controller always had precedence on transmissions. After that, the first one to hit PTT (or in this case the first one that the server recognizes) gets precedence.

 

I maintain that fixing the latency issue will go a long way towards fixing the issue you described where a controller can't get a PTAC clearance out before the pilot plows through the localizer. I say that because from my experience flying in busy events, controllers don't wait for the frequency to be clear, at least not as long as pilots do. (And rightly so.) If they have an instruction to deliver, they will send it as soon as the last pilot stops talking. What happens far too often, though, is that another pilot will start transmitting BEFORE he hears the controller begin his next instruction, and now the pilot has stepped on the controller, and the controller has to start over. That's because of latency, as I described in detail in my last post.

 

That being said, we'll never get rid of latency altogether, because we can't make packets travel across the internet instantaneously. So there will always be some chance of a pilot stepping on the controller's important transmission. And as we've both said, the chance of that happening goes up the more people there are on the frequency, and in busy events we get an unrealistic number of pilots on a single frequency. So reducing the latency is job one, but there could still be a need for something like what you're describing, where the server prioritizes transmissions, for the extremely busy events where they facility is understaffed for the load.

 

Again, my main point is that the latency is the prime culprit here ... it makes frequency congestion so much worse.