Connection erratic under Arch.

[paulscottrobson]

Hi. I've been connecting mostly successfully with XSquawkBox 2.1 on Arch Linux 64 bit. However, occasionally the connection breaks. As you appear to be connecting both on setup audio and connection to the network this means I have to do a howlround test by tuning both radios to an unused frequency, not in itself a problem, and it's usually fixed by disconnect/reconnect. Once it's working it seems to be fine - it's the connection/detection part that seems to throw it.

Don't have any problems with audacity which uses portaudio as its main library. Have experimented with some python scripts which use the library requesting 48Khz sink/source, seems to be fine.

I note the code has a more detailed log, but I can't figure out how to turn this on. If it requires the rebuild of a debug version fair enough (I guess it's built on Ubuntu 18.04 .... Conan seems to really need a VM).

(Most of this log is portaudio being noisy to stdout which seems to be its thing.)

log.txt

The important bit is the following. This is present when it fails only. I think the first is just a warning, as it happens occasionally on successful connections I think (! - this bug is not repeatable consistently but is regular).

ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred Expression 'err' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3350 Expression 'ContinuePoll( self, StreamDirection_In, &pollTimeout, &pollCapture )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3891 Expression 'PaAlsaStream_WaitForFrames( stream, &framesAvail, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4269

(There appears to be nothing in the XPlane log. The text displays 'voice connected' even when it hasn't. Really need a more detailed log to investigate what's going on)

Using a snd-hda-intel motherboard sound card with an NVIDIA card with nvidia card disabled in modprobe.conf.

[paulscottrobson]

Follow up. Switched to Ubuntu 20.04 on the grounds that this might be more reliable as it's built on 18.04. It does appear to be more reliable on what I've tried so far - it connects more often and my webcam doesn't cause it to barf. But it still does occasionally generate that same error (with slightly different line numbers due to versioning).

Expression 'err' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3350 Expression 'ContinuePoll( self, StreamDirection_In, &pollTimeout, &pollCapture )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3891 Expression 'PaAlsaStream_WaitForFrames( stream, &framesAvail, &xrun )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 4269

[paulscottrobson]

After trying many suggestions the solution appears to be (on Arch, not tested on Ubuntu) the latency of pulseaudio-alsa. This can be seen by "pacctl list sinks | grep Latency". By default on my machine this comes out about about 90us

This is due to two settings in /etc/pulse/daemon.conf - these are default-fragments and default-fragment-size-msec. These default (apparently !) to 4 and 25 respectively which appear to be high values, leading to a high latency value. Dropping these to 3 and 5 (which seem to be commonly recommended) seems to have solved the problem on my Arch setup. It has not (as yet) had any other impact on my system. These reduce the latency to about 15us

On Ubuntu 20.04 the deb package has the same daemon.conf installed so presumably has the same values.

This was useful https://juho.tykkala.fi/Pulseaudio-and-latency ; this Steam report here https://github.com/ValveSoftware/SteamOS/issues/433 is the same problem.

Suggestion: add a short note to the documentation suggesting that if the problem occurs under Linux (random connection or non connection) try reducing the values in /etc/pulse/daemon.conf. It can be accurately diagnosed I think for looking for the "Expression 'PaAlsaStream_WaitForFrames" lines when running XPlane from a console. I don't know if it is possible to detect that failure and put a warning in the text box or not.