Fedora 34 audio issues

[A6GibKm]

Since Fedora 34 uses pipewire, the hack heuristic used in #6 does not work anymore.

[JGCarroll]

Does it work any better if you unset PULSE_LATENCY_MSEC entirely?

Assuming it's respected by Pipewire (E.G, maybe it's handled in the Pulseaudio client side libs which would still be used), then I'd presume that activating it would be detrimental to Pipewires different buffer model.

Of course, it could be that it isn't respected by Pipewire at all and an alternative solution would be needed.

Fundamentally Pipewire is supposed to offer much better dynamic latency adjustment than Pulseaudio, so my initial guess is that specifying a latency like this is probably counter intuitive.

[A6GibKm]

I tried setting it to `` and to set it to 120 and `200`. In all cases it has crackling sound... sometimes.

[JGCarroll]

According to the FAQ, PULSE_LATENCY_MSEC should still have some effect, but personally I've never noticed it be that reliable.

In the Snap package I experimented with setting SDL_AUDIODRIVER=alsa and removing PULSE_LATENCY_MSEC, despite it then using the Pulseaudio-ALSA plugin which introduces more indirection, it seemed to work better for many users; where people would say it would load with audio corruption 100% of the time on the first boot of the login session but then never have the problem again until the user restarted the machine. Unfortunately with Pipewire being new I've no idea if it works the same.

I'm unsure how well this translates to Flatpak, you might need to set ALSA_CONFIG_PATH to the location of a file containing something like this to actually bring it all together (otherwise it might actually just try use ALSA raw).

[A6GibKm]

I was not able to make PULSE_LATENCY_MSEC work consistently. I did try with all combinations PULSE_LATENCY_MSEC=X flatpak run --env=PULSE_LATENCY_MSEC=X com.jagex.RuneScape with both environment variable overrides or with only one of them.

[JGCarroll]

Hello again,

Someone on the forums has said that they've had a similar situation on Arch with Pipewire, I'd asked them to try the snap out just for comparison sake and allegedly it works completely fine for them. I was hesitent on recommending it here because I wanted to avoid recommending "competition" when there was no evidence of it fixing the problem, but I'd be curious to hear if it helps. If so, this seems like the kind of problem that might be fixable by changing the Pulseaudio libs shipped with the Flatpak, but whether this is trivial/viable etc I'll leave to the maintainers.

https://secure.runescape.com/m=forum/forums?409,410,514,66216866,5,346543089

[AsciiWolf]

Same issue on Fedora 34 with latest pipewire-0.3.30-2.fc34.x86_64.

[weedmic]

I am not using Fedora, but on KDE on Mint 19.1, I changed my icon to do the following command when starting:

flatpak run --env='PULSE_LATENCY_MSEC=100' --env='vblank_mode=0' 'com.jagex.RuneScape'

[Mossy93]

I am on Fedora 35 and I have tried setting PULSE_LATENCY_MSEC as low as 20 and as high as 2000 with no luck. The only time I didn't have trouble was when I booted up and launched the game to perfect audio. However on the next launch it was just as crackly as ever

[Espionage724]

On Fedora 36, RS3 (native, not sure about flatpak) can use pipewire or pulse through SDL with one of these:

SDL_AUDIODRIVER='pulseaudio'

SDL_AUDIODRIVER='pipewire'

I don't know if Fedora is forcing a default, but it might be helpful to force pulseaudio to be used and then pass the latency environment variable.

[nmlynch94]

I suspect this may be resolved by #204.

[Garbee]

Probably not. The hard-coded env variable in the RS script was included way after this thread started.

[nmlynch94]

Ah, I think I was thrown off by their reuse of version numbers. Thank you.