Audio failing randomly

[Tyler Masters 1436008]

OS: Kubuntu 18.04

 

Log.txt - https://pastebin.com/E4e9LVP7

 

Issue: Audio connection drops out/fails randomly and without warning or notification. Sim will remain running and connected to VATSIM network, and text communications will still work, but the audio (incoming and outgoing) will simply cut out. The issue seems to be most likely to happen when there is a silence in the audio, such as when the ATIS recording ends and there is a silence until it starts up again, however it also cut out mid-transmission. It also occasionally fails on connection to the network.

 

Disconnecting from the network and connecting again gets the audio working again, until it randomly cuts out once more.

 

The following screenshots are the DRT from a testing session on the ground during an event:

 

Here is an example of a failure right on connection. Notice the number of audible channels: https://imgur.com/fcbzks1.png

 

And here is an example from a few seconds after the audio cut out mid-transmission. No noticeable issues except that the number of audible channels remains stuck at 2, when it should vary based on how many stations are transmitting. ATIS was tuned to COM2 and COM1 was tuned to approach. https://imgur.com/ZGnr47I

 

Please advise if more testing or info is needed. This is a repeatable issue for me.

[Christopher Collins]

OS: Kubuntu 18.04

 

Log.txt - https://pastebin.com/E4e9LVP7

 

Issue: Audio connection drops out/fails randomly and without warning or notification. Sim will remain running and connected to VATSIM network, and text communications will still work, but the audio (incoming and outgoing) will simply cut out. The issue seems to be most likely to happen when there is a silence in the audio, such as when the ATIS recording ends and there is a silence until it starts up again, however it also cut out mid-transmission. It also occasionally fails on connection to the network.

 

Disconnecting from the network and connecting again gets the audio working again, until it randomly cuts out once more.

 

The following screenshots are the DRT from a testing session on the ground during an event:

 

Here is an example of a failure right on connection. Notice the number of audible channels: https://imgur.com/fcbzks1.png

 

And here is an example from a few seconds after the audio cut out mid-transmission. No noticeable issues except that the number of audible channels remains stuck at 2, when it should vary based on how many stations are transmitting. ATIS was tuned to COM2 and COM1 was tuned to approach. https://imgur.com/ZGnr47I

 

Please advise if more testing or info is needed. This is a repeatable issue for me.

 

I'll have a bit of a dig when I find some time since audiable_channels should be initialised correctly at all times that active_channels is valid, otherwise this doesn't look like an XSB or AFV-Native issue right now.

 

There's a known issue with XSB2 not automatically reconnecting to voice servers when they time out, but your log shows none of those symptoms. It does require 10 seconds for the timeout to actually get reported however, so if you're intervening before that, you could be masking that issue.

[Tyler Masters 1436008]

Are there any tests I can perform for you to gather more info? As of right now, XSB is the only sane pilot client available for Linux and I'd love to help you get it working.

[Christopher Collins]

Are there any tests I can perform for you to gather more info? As of right now, XSB is the only sane pilot client available for Linux and I'd love to help you get it working.

 

Barring there being a timeout that's not being allowed to fully develop, right now everything is pointing to a portaudio/alsa (and beyond) related failure. This can be verified by, once connected, if iterations are still continuously increasing, and the source counts are realistic, and underruns are holding at 0, but you have no sound, then something has probably broken in the audio layer outside of XSB/AFV-native in a way that portaudio is not reporting back to AFV-Native (or AFV-Native simply isn't looking for). If iterations are not changing, then AFV-Native's processing thread has probably crashed and you'll need to find any debug messages related to that so I can work out where and why.

 

Bear in mind that you also need to keep audio hardware limitations in mind with this. I can't tell what hardware you are using when the failure takes place, but as always:

• We do not support bluetooth headsets as A2DP/Handset Profile are too limited to handle the mixture of simulator audio and AFV-Native audio and it's too hard to guarantee that all the preconditions required for it to work are met. (If you can get it to work, great, but if it's not working, I'm sorry, there's nada I can do - the big limiting factor is Bluetooth audio devices can ONLY handle mono in full duplex, so software or the OS grabbing them for stereo output tends to break capture or do other things we really can't predict or work around).
  
• We can not support device hot plugging and changing whilst connected. If you're using USB Audio and there's any instability with your USB bus/drivers at all, can't help you with that - you'll need to address that issue yourself - preferably by eliminating anything that's causing devices to flap. Largely, we work on the [Mod - Happy Thoughts]umption that devices do not go away once connected - if your OS can hide the flap, it's all good, but if it can't, there's nothing we can do in the AFV-Native end without making everything very complicated.
  
• We cannot support interactions that occur at any layer past ALSA on Linux at this time. We only have the ALSA driver in the version of portaudio we're using, and anything past that is typically distro provided, such as the pulseaudio bridge that the Ubuntu flavours use.

 

I can only suggest you run X-Plane from a terminal and capture both stdout and stderr, and check for any error reports from libasound or other bits that are involved in the audio path.

 

If you've got linux development skills, feel free to grab AFV-Native off of github and see if you can use the test programs to provoke a failure in the portaudio driver to localise the problem. They only really test the output path, but it sounds like that may be where you're having problems anyway.

[Tyler Masters 1436008]

Beta 6 appears to have fixed this issue. 1+ hour and no audio failures. Thanks for your time.

[Christopher Collins]

Beta 6 appears to have fixed this issue. 1+ hour and no audio failures. Thanks for your time.

 

Thanks for updating me - this leads me to believe it was a variant of the voice server timeout issue I fixed.

 

Happy flying!