PulseAudio Latency

[bryce-carson]

Using export PULSE_LATENCY_MSEC=100 in the rs3-user-config file does not work as expected. The expected behaviour is for the effect to be applied for the first running instance of Runescape 3 upon a new session in the desktop environment.

The observed behaviour:

1. With the configuration file already present, upon login the first launched instance of RS3 from the Gnome Overview, for example, does not have the proper latency and audio is corrupted;
2. The following instances launched using Gnome do not correct the issue;
3. Running runescape.rs3 from the terminal causes the configuration file to be found and read, but the first launched instance does not have the proper latency still.
4. Running Runescape 3 from the command-line one more time then has the proper latency, and subsequently any instances launched from Gnome will also have the proper latency.

The configuration file, as documented: cat ~/snap/runescape/current/rs3-user-config export PULSE_LATENCY_MSEC=100

[JGCarroll]

I don't think the problem is quite how it's observed here. From what I can tell, the rs3-user-config file is read every time, and if you had something in it like xmessage "Hello world", E.G via echo 'xmessage "Hello World"' > ~/snap/runescape/current/rs3-user-config you'd see that the GUI prompt would appear every single time, there shouldn't be any difference in launching it via the shell or launching it via CLI, because they both run the exact same code.

Instead, this is a much deeper problem with the game engine and it's interactions with Linux that is to say, not trivially resolvable by either myself or Jagex.

Jagex officially recommends PULSE_LATENCY_MSEC=100 and tries to set CAPS_SYS_NICE on the engine, which uses this to give the audio threads realtime scheduling priority. In theory this makes sense, the audio corruption is a buffer underrun which means that the game isn't giving the soundcard enough data reliably to get quality audio, so setting the highest priority available would mean this doesn't occur. I had had a small discussion with Jagex previously about achieving this without CAP_SYSNICE; because neither the Snap nor Flatpak are compatible with CAP* attributes.

In practise however, on Ubuntu with their Apt native installation, it still happens anyway. It isn't actually a reliable fix even on the only officially supported configuration that exists.

On Ubuntu 20.04 it happens much less often in this Snap with 150ms latency and no realtime threads, personally for me, I didn't experience an issue for nearly an entire month, whereas on 18.04 it still happens fairly frequently. There's huge variance in the operating system its being run on, due to whatever Pulseaudio default configurations, sound card drivers kernel side, etc.

And even more curiously, I have never once heard the Windows client running in Wine do anything similar, despite them having basically the exact same architecture.

The exact value, 150ms, is picked because its what works best for me, back when I was initially building this on an i7-4790k which is still a very fast CPU and more than capable for RS. Some other people suggest using 60ms, others 100; and yet the problem is that no single value seems to work reliably across different computers, and as you've observed, it's not even reliable amongst individual computers across repeated executions. There isn't really enough input to decide on whats an actual good default here, but I think given the nature of the game, 150ms is acceptible enough. I do not think CPU speed correlates to the value in any predictable fashion.

So what can I recommend?

Personally, I noticed that the game seems to have suprisingly different characteristics when it has the variable SDL_AUDIODRIVER=alsa set, as long as you also unset the pulse value entirely, so for example,

echo 'SDL_AUDIODRIVER=alsa' > ~/snap/runescape/current/rs3-user-config echo 'PULSE_LATENCY_MSEC=""' >> ~/snap/runescape/current/rs3-user-config

What happens generally with this set, is the game will ALWAYS have the audio corruption on the first run, but any subsequent runs have something like a 99.9% success rate until the OS is rebooted. And this is despite the fact that in the Snap environment, the ALSA backend will actually be using Pulseaudio anyway, which means for some reason adding more indirection seems to improve the situation, showing to me there's something very deeply flawed going on, and it almost certainly can't be fixed by anyone other than Jagex themselves.

I did for a few months have the ALSA backend as default to do some testing, whilst the majority of people repeated what I said, it always failed the first time but then was reliable every time thereafter; there was also one user who said it entirely broke the Snap so I reverted it to how it currently is.

Tl;Dr

There isn't an easy fix, and all that can be done is mitigations, but try setting the ALSA flag, and although it's annoying you'll have to reload the game client once every time you boot the OS, it is generally speaking superior and doesn't rely on spam opening the client until it works.

[bryce-carson]

Thank you for the detailed response.

[JGCarroll]

I'll keep this open for the benefit of other users who might be interested in seeing it as an active issue and as something brought to my attention. Whilst there isn't anything I'm aware of that I can do right now and the ball is mostly in Jagex's court, it's still something I do consider a major issue and there might end up being something in the future that improves upon things. Chances are this issue might stay inactive for months/years, but simply being inactive doesn't mean it's not valid and if this particular issue remains closed, there'd probably be another one opened for the same thing in the future anyway.

[JGCarroll]

As a minor update to this, runescape.rs3 now takes parameters -p for the Pulseaudio latency, and -a to try the ALSA backend variables. ( E.G: runescape.rs3 -p 100 or runescape.rs3 -a ) I'd been trying to get the snap to work with gamemoded that's becoming default in various distributions, but it doesn't appear to actually be particularly useful in this instance and so Jagex are still the ones with the best chance of proper fixes.