Nick Papandreou Posted March 4, 2017 at 06:51 PM Posted March 4, 2017 at 06:51 PM Not sure if i'm performing a cardinal sin here by reviving such an old thread, but I guess I´ll take my chances. Have there been any new updates regarding improved voice codecs? The ancient roger-wilco like voice quality, especially the lag keeps me from getting back behind a scope. I just can't deal with it now that I work on the airwaves from day to day. Is there any light at the end of this tunnel? Not really. In short it seems that new codecs will break compatibility with Fsinn and Squawkbox and thus with fs9, fs2002 and we don't want that. So we'll have to wait until Swift (a new client) is finished, although it's been developed for almost 4 years and there are no official news regarding it's progress for almost a year. Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 4, 2017 at 10:12 PM Posted March 4, 2017 at 10:12 PM Not really. In short it seems that new codecs will break compatibility with Fsinn and Squawkbox and thus with fs9, fs2002 and we don't want that. A solution has been put up for consideration that will allow the old clients to continue with their old codec while new clients can use a new codec. Essentially, the new clients will transmit two streams, one on the old codec, one on the new, and the server will send the appropriate codec to each client based on whether it is old or new. One of the devs has looked into this solution but he hasn't had a lot of time to work on it and I don't know how viable it is. But, the point is that we don't necessarily have to phase out FSInn and Squawkbox before we can have a new codec. Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. This seems hyperbolic to me ... have you actually seen anyone say that they like the lag? Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Ryan Geckler Posted March 4, 2017 at 10:59 PM Posted March 4, 2017 at 10:59 PM Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. Must be one of those "alternative facts". Ryan Geckler - GK | Former VATUSA3 - Division Training Manager VATSIM Minneapolis ARTCC | FAA Miami ARTCC Link to comment Share on other sites More sharing options...
Thimo Koolen Posted March 5, 2017 at 09:10 AM Posted March 5, 2017 at 09:10 AM You can't keep supporting those old clients forever though. Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. Sure, there are always people who like it. However, the majority does not. Of course a new codec wouldn't need to be crystal clear, but it will be a huge improvement anways. ACCNL4 (Training Director) - Dutch VACC Link to comment Share on other sites More sharing options...
Johnny Coughlan Posted March 5, 2017 at 10:09 AM Posted March 5, 2017 at 10:09 AM Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. Are you being serious?, you say people like the quality and latency?. This kind of attitude has infuriated me for years, I've seen good controllers and pilots leave because of this issue and you say people like it?. This is the only topic that actually annoys me, my kid who is starting to get into flightsim because he's seen his dad do since he was born and who plays online on other various platforms regularly communicating with his friends laughs at the quality of VOIP on this network and won't go near it because if that and I dont blame him because it's easy for me as I'm used to it from over 13 years of listening to it. This is the generation who are going to populate our network, young teenagers and young adults who are used to 'clear' VOIP looking to enhance their flightsim experience. It doesn't have to be teamspeak quality but even if the lag was reduced it would a step in the right direction. Link to comment Share on other sites More sharing options...
Nick Papandreou Posted March 5, 2017 at 10:15 AM Posted March 5, 2017 at 10:15 AM This seems hyperbolic to me ... have you actually seen anyone say that they like the lag? You are right, it is hyperbolic. It helps sometimes to stir things up, make things happen, good things As others have said, after more than 15 years it's time to move forward. And your contribution Ross toward that goal has been tremendous. Link to comment Share on other sites More sharing options...
Halldor Bui Jonsson Posted March 5, 2017 at 12:25 PM Posted March 5, 2017 at 12:25 PM Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. Thanks for the replies, Johnny, please be more careful how you use quotes in replies. I didn't write what Nick said The correct quote is: Plus, it seems there are some who like the current voice quality (including the lag that makes pilots and controllers to talk on top of each other and creates frustration) and don't see any need of moving forward. It seems VATSIM continuing to support software for such a long lifetime may be hurting the organization more than helping it if it's literally holding back progress. I doubt I'm the only one who can't bear the roger wilco protocol anymore. -------------------- Best regards -------------------- Halldor Link to comment Share on other sites More sharing options...
Board of Governors Simon Kelsey Posted March 5, 2017 at 03:58 PM Board of Governors Posted March 5, 2017 at 03:58 PM Gents, It doesn't have to be teamspeak quality but even if the lag was reduced it would a step in the right direction. I don't want to pour cold water on this but those who are hoping for a new codec to solve all the problems of latency and pilots stepping on each other are going to be very disappointed. Unfortunately the latency issue is 1) inherent to digital audio in general and 2) particularly inherent to the Internet as a delivery medium. You are never going to have a situation where you have all stations receiving a transmission at exactly the same time. This is even the case with broadcast digital audio: for instance, I have two DAB radios at home, one in the living room and one in the kitchen. If I tune both to the same station, the audio from the one in the living room is slightly behind the kitchen. Why? Because despite the fact that the RF signal is travelling at the speed of light and therefore for all intents and purposes arrives at both radios at exactly the same instant, and (clearly) both radios are using the same codec, the one in the living room is an older unit with, presumably, slower hardware. Thus, it takes a measurably longer time to decode the digital signal and convert it to analogue audio. The same is true of internet VOIP systems. Think about the path your transmission takes: - You speak (analogue) in to a microphone, which generates an analogue audio signal. - At some point this analogue signal has to be converted to a digital signal by an audio interface -- i.e. your PC sound card (in the case of a USB headset, these have audio interfaces included in them to do the A/D conversion). This conversion in itself takes a small, but measurable amount of time: things are a bit better now, but I can recall my original USB headset exhibited a fairly significant delay between, for instance, my speaking words in to it and them being recorded, in the order of several tens or even hundreds of milliseconds. This is before the VATSIM codec even comes in to the picture. - This digital signal is then intercepted by the voice software and compressed (i.e. encoded -- the 'code' side of the codec (which is short for coder/decoder). This also takes time -- depending on the level of compression that needs to be achieved, the general efficiency of the codec, the level of error-checking required and, indeed, the hardware upon which said codec is running -- if you are running a slow PC, or your PC is weighed down running lots of CPU-intensive software (I wonder what software VATSIM pilots might be running that fits that category?), the audio encoding process will take longer. - This encoded audio now needs to be distributed from your PC to the voice server. The amount of time it takes the packets to reach the server is dependent on all sorts of factors, not least the physical distance between you and the server, the quality and bandwidth available on your internet connection (lots of people do things like stream their flights, watch Youtube videos, have family/housemates who may be downloading or streaming on the same connection etc -- all things which very significantly impact on latency). - From the server, this audio now needs to be distributed to all other clients in the voice room. VATSIM is a global community, and it is quite common to have people in a voice room on opposite sides of the globe, some in countries with less-than-excellent Internet connectivity, some on high-speed fibre broadband and others on satellite connections and everything in between. Clearly, it is going to take longer for the data to travel from a server in London to a client in Australia than it does to travel from the server in London to me just a couple of hundred miles up the road in Manchester. - When the audio arrives at the client, it then has to be decoded (the exact time taken dependent on all the factors mentioned above that can also affect encoding), then converted by your sound card from digital to analogue (again, additional small but measurable latency that will be unique to different users). When you add up all of the variables that are unique to each user -- you can hopefully see how it is incredibly difficult, if not impossible, to have a situation where everybody receives the same audio at exactly the same time (which is the main issue -- not just the latency itself). This is before we get in to the subject of error checking -- because an Internet connection is by nature not a point-to-point connection like dialling someone on a copper phone line, data packets travelling between the 'transmitter' and the server, and between the server and the clients (even individual packets from the server to an individual client) do not follow the same paths. This means that packets end up arriving out of order or not at all. The codec can put up with some packet loss, but if too many packets are lost or out of sequence this is when you get breaks and dropouts in the audio. The solution is to put more error checking in -- but this typically requires larger buffers, more bandwidth and therefore more latency. There is no free lunch. People talk a lot about Teamspeak, Skype and Facetime etc, but as someone who uses these (particularly the last two) technologies on a daily basis in a professional environment, I can [Mod - Happy Thoughts]ure you that the quality of these ranges from excellent to atrocious, and this can be the case even within a single call, generally without warning. The latency is also significantly greater than VATSIM comms. Out of double-digit numbers of internet VOIP calls every day, I would say at least 50-70% experience some level of dropout or poor/unintelligible audio. The biggest issues are quality of internet connection and quality of hardware (in other words, people with good PCs, running no extraneous software other than Skype, and wearing a good quality headset mic, with a good quality wired internet connection rather than WiFi, generally sound great -- change any of the above and you start experiencing problems). A new codec may improve baseline quality slightly, but it is unlikely to change the latency significantly and it certainly won't change the differences in latency experienced by different users. Vice President, Pilot Training Link to comment Share on other sites More sharing options...
Board of Governors Simon Kelsey Posted March 5, 2017 at 05:38 PM Board of Governors Posted March 5, 2017 at 05:38 PM PS: A solution has been put up for consideration that will allow the old clients to continue with their old codec while new clients can use a new codec. Essentially, the new clients will transmit two streams, one on the old codec, one on the new, and the server will send the appropriate codec to each client based on whether it is old or new. One of the devs has looked into this solution but he hasn't had a lot of time to work on it and I don't know how viable it is. This seems like a very complex solution. Would it not be easier to 'simply' put together a standalone voice client a la AVC (which I am sure you will remember) to tide SB/FSINN etc users over? Vice President, Pilot Training Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 5, 2017 at 05:39 PM Posted March 5, 2017 at 05:39 PM A new codec may improve baseline quality slightly, but it is unlikely to change the latency significantly and it certainly won't change the differences in latency experienced by different users. VATSIM's latency issue is not related to the codec ... it is baked into the network architecture. It was designed for high-latency modem connections and has a very high buffer delay built in (both in sending AND receiving) so that a given data packet can be significantly delayed and the playback is still uninterrupted. It's important to note that this buffering is not about preventing packet loss or maintaining packet order ... it's all about preventing pausing in playback. If I remember right from my chats with the devs that are looking into this in detail, this delay is a few hundred milliseconds on each end, adding up to something between a half second and a full second of latency just to prevent pauses in the playback due to slow internet connections. That may have been necessary back when the code was first written a decade or two ago, but it is overkill now. Obviously you're right when you say that there is latency coming from other parts of the system, but on modern multi-core computers and broadband network connections, that latency can be an order of magnitude smaller than the latency introduced by VATSIM's buffering. That's not an exaggeration ... the VATSIM buffering can be 10 times the latency created by the codec or the network transmission. Reducing that buffering delay to a value that is more appropriate for the speed of modern network connections has the potential to eliminate perhaps 75% of the delay between when User A presses PTT and when User B starts hearing the audio. Sometimes more, sometimes less. it is incredibly difficult, if not impossible, to have a situation where everybody receives the same audio at exactly the same time (which is the main issue -- not just the latency itself). I beg to differ ... the latency is the main issue. Even if we could achieve simultaneous reception by all users (which I agree we cannot) we would still have people stepping on each other. The higher the latency, the greater the potential for users stepping on each other. The size of the delay I referred to in my last paragraph above, between the time User A presses PTT and when User B starts to receive the audio, is directly proportional to the chance for User B stepping on User A. We don't start transmitting if we know another user is transmitting, therefore the "opportunity" for User B to step on User A exists between when User A keys up and when User B starts hearing the audio. Anything we can do to shorten that delay will reduce the chances of users stepping on each other. It doesn't matter if everyone (User B, User C .. User Z) starts to hear User A's audio at the exact same time ... that won't help one bit ... it's the size of the delay that matters, not the difference in delay from one user to the next. All that being said, there is still some latency in the codec, and moving to a new codec could still help with the latency issue if the new codec has much lower latency, but the bulk of our latency issue is introduced after the codec does its job on the transmitting side, and before the codec does its job on the receiving side. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Halldor Bui Jonsson Posted March 5, 2017 at 08:08 PM Posted March 5, 2017 at 08:08 PM Thanks for the detailed response on this Ross. Here´s to hoping this issue can/will be solved sooner rather than later. -------------------- Best regards -------------------- Halldor Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 7, 2017 at 12:50 AM Posted March 7, 2017 at 12:50 AM PS: A solution has been put up for consideration that will allow the old clients to continue with their old codec while new clients can use a new codec. Essentially, the new clients will transmit two streams, one on the old codec, one on the new, and the server will send the appropriate codec to each client based on whether it is old or new. One of the devs has looked into this solution but he hasn't had a lot of time to work on it and I don't know how viable it is. This seems like a very complex solution. Would it not be easier to 'simply' put together a standalone voice client a la AVC (which I am sure you will remember) to tide SB/FSINN etc users over? That would be somewhat easier from a software development perspective, but it has the disadvantage of requiring users of FSInn and Squawkbox to download and install new software. The dual stream solution provides a way to transition to the new voice architecture over time with no cutover date and without leaving anyone behind if they didn't get the memo, or didn't take the time to download and install the new software. Definitely pros and cons either way. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Jonathan Fong Posted March 7, 2017 at 11:01 AM Posted March 7, 2017 at 11:01 AM That would be somewhat easier from a software development perspective, but it has the disadvantage of requiring users of FSInn and Squawkbox to download and install new software. The dual stream solution provides a way to transition to the new voice architecture over time with no cutover date and without leaving anyone behind if they didn't get the memo, or didn't take the time to download and install the new software. Definitely pros and cons either way. Frankly speaking, I don't see the issue with FSInn/SB users downloading an additional 'voice radio' application... Users of those applications are acknowledging that they are using software that is no longer being developed when downloading and installing it, so I don't see a reason for objections. The network needs to move on. Plus, it can't be that complicated an install, since such a program would be standalone with no need to interact directly with any other pilot client - only to be able to use the new voice codec and to be able to set frequencies manually through some sort of UI (or even pull said frequencies from the sim itself, which in theory shouldn't be a difficult task for anyone used to programming external programs for X-Plane/MSFS). I'd bet you could even take some of the code for pulling said data from existing applications such as vPilot. Granted, some modifications to the network code would have to be made to allow for double connections with the pilot client and voice client, but I'm sure such issues would be simple to resolve with some sort of distinct signature sent by the voice client. Although I can understand the argument for legacy support, using such a 'double codec' system would not fully resolve the issue of undecipherable voice communications due to those still using the Roger Wilco codec still being, well, undecipherable, even though other transmissions would be far clearer. Better to just move to a new codec with lower latency/buffer programmed in and write a simple program to allow those VATSIM users who must use clients no longer under development to talk on voice with the new codec. Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 7, 2017 at 03:41 PM Posted March 7, 2017 at 03:41 PM Yeah, the install would not be complicated. That's not the issue. And development of the voice client would not be complicated. That's not the issue, either. The issue is the fact that using a new voice client means that we have to schedule a hard cut-over date on which every single VATSIM user must switch to a new client in order to have any voice comms as all. I say "every single VATSIM user" because users of both old and new clients (pilot or ATC) would all have to switch at the same time. Anyone that doesn't get the memo, or anyone that doesn't have auto-update turned on in vPilot, or anyone that has trouble installing the latest version of any of the maintained pilot or ATC clients, will not have voice comms the day of the cutover. I'm not saying it wouldn't be doable, and there are things we could do to help ensure everyone is prepared for the cut over date such as periodic broadcast messages on the days leading up to the switch, but I think we'll find that a solution that allows us to smoothly phase in the new voice system will be much more acceptable to the BoG. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Jonathan Fong Posted March 8, 2017 at 07:48 AM Posted March 8, 2017 at 07:48 AM Yeah, the install would not be complicated. That's not the issue. And development of the voice client would not be complicated. That's not the issue, either. The issue is the fact that using a new voice client means that we have to schedule a hard cut-over date on which every single VATSIM user must switch to a new client in order to have any voice comms as all. I say "every single VATSIM user" because users of both old and new clients (pilot or ATC) would all have to switch at the same time. Anyone that doesn't get the memo, or anyone that doesn't have auto-update turned on in vPilot, or anyone that has trouble installing the latest version of any of the maintained pilot or ATC clients, will not have voice comms the day of the cutover. I'm not saying it wouldn't be doable, and there are things we could do to help ensure everyone is prepared for the cut over date such as periodic broadcast messages on the days leading up to the switch, but I think we'll find that a solution that allows us to smoothly phase in the new voice system will be much more acceptable to the BoG. Good point. Maybe we could have a hybrid of both solutions - have a hybrid voice codec system (at least temporarily) as well as a voice client application in case users that have to use SB4, FSInn or an non-updated version of modern clients can still use the new codec... Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 8, 2017 at 02:21 PM Posted March 8, 2017 at 02:21 PM Maybe we could have a hybrid of both solutions - have a hybrid voice codec system (at least temporarily) as well as a voice client application in case users that have to use SB4, FSInn or an non-updated version of modern clients can still use the new codec... Yeah, that would be good, but I think we'd only want to do that if they didn't have an option to upgrade their client. Like if swift was not an option yet. If they have an option to move to a modern client, then having the standalone voice client would run counter to the goal of phasing out the legacy clients ... it would take away incentive to upgrade. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Lindsey Wiebe 1101951 Posted March 8, 2017 at 06:21 PM Posted March 8, 2017 at 06:21 PM We could do the hybrid but when someone logs in with a legacy system a warning is issued "you are using a legacy program which will be fazed out/ discontinued on Jan 1, 2018 please visit https://www.vatsim.net/pilots/software to download current supported software" ? Mr. VATSIM P2 Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 8, 2017 at 06:30 PM Posted March 8, 2017 at 06:30 PM We could do the hybrid but when someone logs in with a legacy system a warning is issued "you are using a legacy program which will be fazed out/ discontinued on Jan 1, 2018 please visit https://www.vatsim.net/pilots/software to download current supported software" ? I think we would do that whether we used the hybrid approach or not. And I think it would have to be done in a more overt way than the current server messages you see when you first connect. I doubt anyone reads those after the first time they connect, if they even read them then. I'm thinking maybe a private message would get their attention better. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Trent Hopkinson Posted March 8, 2017 at 11:14 PM Posted March 8, 2017 at 11:14 PM in case users that have to use SB4, FSInn or an non-updated version of modern clients xsquawkbox VRC Euroscope3.2 Euroscope2 + TAAAATSmod (Our TAAATS mod developer lost all their mod files, though is slowly developing an entirely new client... as a real world ATC, development is slow) Vstars .... etc. Trent Hopkinson YMML. www.youtube.com/musicalaviator WorldFlight 2002,2008,2009, 2011, 2012, 2013 & 2015 Link to comment Share on other sites More sharing options...
Board of Governors Simon Kelsey Posted March 9, 2017 at 12:52 AM Board of Governors Posted March 9, 2017 at 12:52 AM Yeah, the install would not be complicated. That's not the issue. And development of the voice client would not be complicated. That's not the issue, either. The issue is the fact that using a new voice client means that we have to schedule a hard cut-over date on which every single VATSIM user must switch to a new client in order to have any voice comms as all. I say "every single VATSIM user" because users of both old and new clients (pilot or ATC) would all have to switch at the same time. Anyone that doesn't get the memo, or anyone that doesn't have auto-update turned on in vPilot, or anyone that has trouble installing the latest version of any of the maintained pilot or ATC clients, will not have voice comms the day of the cutover. Indeed. Which, presumably, would be an excellent prompt for them to go and grab the new voice client, wouldn't it? Ultimately, I would suggest it doesn't matter how much publicity you put out -- the day that the old clients are phased out you'll still get people asking why SB no longer works, whether there's a dual-running period or not -- in fact, perhaps even more so as said users won't notice any difference in their experience when they log on. Any upgrade that breaks compatibility is going to cause some disruption for a period, whether it's at the moment of voice codec switchover or the moment of SB/FSINN et al deprecation. My suggestion would be that dual running seems like a very complex situation which would significantly reduce the impact of the upgrade (after all, if legacy client users are still transmitting in the old codec they're still going to sound like they're in a dungeon to everybody else and I would presume they'll still experience the latency issues already discussed) and just postpones the pain until the day that the legacy clients get 'switched off' (at which point a large chunk of legacy client users who have been happily flying away turn up and ask "well what was the problem?"). Ultimately, a few extra pilots on text (the vast majority of which I would imagine will be for no more than a single flight each, or even a portion of a single flight) for a period whilst the new voice client 'settles in' doesn't seem like a particularly large impact to me compared to the rather large volunteer technical effort & resource required to set up a dual running system that sooner or later will have to be torn down again. Still, up to the BoG how they choose to expend their technical resource, I suppose! Vice President, Pilot Training Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 9, 2017 at 04:15 AM Posted March 9, 2017 at 04:15 AM Indeed. Which, presumably, would be an excellent prompt for them to go and grab the new voice client, wouldn't it? I don't think I would use the word excellent, given how jarring and frustrating it would be to connect one day and not have voice comms until you installed new software, especially if you have problems getting that new software running. Don't get me wrong, it wouldn't be the end of the world, but I do think it would be a significantly worse user experience than if we had a transition period. And the real kicker is that everyone would be having that negative experience at the same time. Again, I don't want to make it sound like it would be a complete disaster, but I do think it would be a lot worse than a transition period. There are some things we could do to help people prepare for a hard cutover, like giving everyone access to the new voice client and updated versions of vPilot, EuroScope, etc. ahead of time along with a test server to connect to, but the onus is still on them to take the time to install and test the new software, and I would bet that a good chunk of the user base won't bother, based on an [Mod - Happy Thoughts]umption that they'll have no issues when the cutover day arrives. Ultimately, I would suggest it doesn't matter how much publicity you put out -- the day that the old clients are phased out you'll still get people asking why SB no longer works, whether there's a dual-running period or not -- in fact, perhaps even more so as said users won't notice any difference in their experience when they log on. Sure, there will always be some people that don't get the memo, but we should strive to minimize that. It seems to me that having a transition period is the right way to keep it to a minimum, rather than a hard cutoff. During that transition period we can have automated messaging sent to users on the legacy clients telling them when they'll be phased out. My suggestion would be that dual running seems like a very complex situation You may be overestimating the amount of work a dual stream would require. It wouldn't be much more work than building in the new codec. Consider the fact that the clients already have the old voice code ... we would just need to add the new code and NOT rip out the old. As far as I can tell, the only code that we'd have to write that would be thrown away at the end of the transition period would be some conditional logic added to the voice server so that it could selectively forward the old or the new codec stream on to each connected client based on whether or not it supports the new format. which would significantly reduce the impact of the upgrade I'm more concerned about the negative impact of a hard cutoff than I am about the positive impact of the upgrade. Though I do agree that it would be cool to have everyone move to the new voice system at the same time. Ultimately, a few extra pilots on text (the vast majority of which I would imagine will be for no more than a single flight each, or even a portion of a single flight) for a period whilst the new voice client 'settles in' doesn't seem like a particularly large impact to me compared to the rather large volunteer technical effort & resource required to set up a dual running system that sooner or later will have to be torn down again. Here again I think you're overestimating the required effort ... and I think you're underestimating how problematic it could potentially be to force everyone onto new software all at the same time. As a developer, I cringe at the thought. I'm daydreaming a bit here, but it would be great if we could get into a situation where everyone is running a new client and all of those clients have auto-update functionality, and then we could do a hard cutover to the new voice system and no one would have to do anything on that day. It could actually end up happening that way, [Mod - Happy Thoughts]uming swift is released before we get around to developing a new voice system. Then, once everyone transitions from the legacy pilot clients to swift, we can turn off the old clients and turn on the new voice system whenever it's ready. We could even have the new voice code lying dormant in the client, waiting for a signal from the server to activate it once enough users have moved to the new clients. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Johnny Coughlan Posted March 9, 2017 at 08:13 AM Posted March 9, 2017 at 08:13 AM Are VATSIM too scared to upset the members using legacy clients for possible fear of losing them?. I've seen the opposite in where we've lost members due the the issues mentioned in this thread. Link to comment Share on other sites More sharing options...
Jonathan Fong Posted March 9, 2017 at 10:47 AM Posted March 9, 2017 at 10:47 AM I don't think I would use the word excellent, given how jarring and frustrating it would be to connect one day and not have voice comms until you installed new software, especially if you have problems getting that new software running. Don't get me wrong, it wouldn't be the end of the world, but I do think it would be a significantly worse user experience than if we had a transition period. And the real kicker is that everyone would be having that negative experience at the same time. Again, I don't want to make it sound like it would be a complete disaster, but I do think it would be a lot worse than a transition period. ... Sure, there will always be some people that don't get the memo, but we should strive to minimize that. It seems to me that having a transition period is the right way to keep it to a minimum, rather than a hard cutoff. During that transition period we can have automated messaging sent to users on the legacy clients telling them when they'll be phased out. You do make a good point. If a double codec system would be easy to add to the VATSIM servers, I say why not. Otherwise, I stand by my original point of view that a hard cutoff would be best. It's not like users would COMPLETELY be in the dark - surely we can send automated messages to users on the days after the cutoff to make sure they update their clients, no? Link to comment Share on other sites More sharing options...
Ross Carlson Posted March 9, 2017 at 02:02 PM Posted March 9, 2017 at 02:02 PM You do make a good point. If a double codec system would be easy to add to the VATSIM servers, I say why not. Otherwise, I stand by my original point of view that a hard cutoff would be best. It's not like users would COMPLETELY be in the dark - surely we can send automated messages to users on the days after the cutoff to make sure they update their clients, no? Yes, we could modify the server so that it sends a private message to the user saying they'll be unable to communicate via voice until they update their client. I imagine we'd be doing this anyway, whether we used a hard cutoff or a transition period. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Ernesto Alvarez 818262 Posted March 9, 2017 at 03:45 PM Posted March 9, 2017 at 03:45 PM Are VATSIM too scared to upset the members using legacy clients for possible fear of losing them?. I've seen the opposite in where we've lost members due the the issues mentioned in this thread. users come and go all the time. they cant do that when you stop them from coming back. so yes you can pretty much consider any idea that would cause something like that to happen to die before its even proposed. impatience doesnt pay off in the long run. only gives you temporary satisfaction i prefer the AVC method simply because we've done that before and it gives the network time to wean folks off the old software (once newer software is widely available). i think most folks would use that method just cause of the increase in quality that could be gotten. just like AVC though, the voice client would have to verify you are logged in to the network to avoid the return of trolls Link to comment Share on other sites More sharing options...
Recommended Posts