I have a freshly installed Manjaro KDE on my laptop. Initially, I only did the following:
Updated all packages
Installed Google Chrome via AUR
Installed Steam
Installed ARK Survival Evolved within Steam
(The above was repeated multiple times, each time changing this step) Installed Teamspeak 3/6 / Discord
And now to my problem: when I play on my friend’s server and simultaneously talk using one of the programs mentioned above, a sound glitch occurs very sporadically. It sounds crackly for a moment, my good friend sounds like a robot, and ARK loses all sound. After a few seconds/minutes, it returns to normal.This issue has also occurred with the GNOME and Cinnamon variants of Manjaro. This error occurs with headphones (wired and Bluetooth) and without headphones (integrated speakers). I have already deactivated “suspend on idle” in PipeWire, but it doesn’t help. Neither he nor I know what to do next. Perhaps the kind Manjaro community could help?
Thank you in advance! The entire text was translated with the help of a translation tool. (Sorry for my not so good English!)
If you’re doing the default install from Linux via. Steam then I believe ARK installs the ‘Linux native’ version of the game.
It’s not a good version of the game from what I’ve heard, lots of issues with graphics, performance and possibly sound.
I know I never managed to get it working properly, lots of texture problems, lighting artifacts, repeating dinosaur sounds etc.
I’ve seen people saying you can install Steam inside a Wine/Lutris instance and then install ARK from there so you get the better Windows version. I haven’t tested that myself due to the download size being so large.
Indeed, if a game has a Linux version, this is what installs by default.
However
Is plain wrong.
Just go to the game Properties in the Steam Library (in your real Steam for Linux), and in Compatibility section, select/force Proton 9, it will download/update the game files with the Windows version and run the game with Proton.
Thanks, good to know, I spent a while trying to get the game playable.
I’m looking at it now and I see ‘Proton 9.0-4’ which I’m guessing is the one you’re talking about.
This is the first I’ve heard of that installing/running the windows version of something. Any idea if this an ARK specific thing or should that do the same thing for all Steam games with issues?
You can set a Proton version per game if necessary (like for games which have a Linux version, to force the use of the Windows files, or games that require an old or experimental Proton version), but this is usually not needed. Make sure to set a default Proton version in Steam Settings (usually the latest version, currently Proton 9, soon Proton 10) and you’re good to go.
Thanks for your previous help! I’ve now confirmed that I’m running the Windows version of ARK via Proton. I’ve switched to another Proton version.
However, the specific audio problem persists: game audio occasionally drops out in ARK multiplayer on the Ragnarok map (no robotic voice anymore, just full silence for a few seconds/minutes).
My journalctl logs show these specific messages during gameplay:
kernel: x86/split lock detection: #AC: ShooterGame.exe/... took a split_lock trap at address: ...
kernel: Bluetooth: hci0: SCO packet for unknown connection handle ...
These split lock errors consistently appear when the audio issues occur, and they are present from various ARK/Steam processes. They do not appear in singleplayer or on other maps, pointing to a severe load condition unique to multiplayer Ragnarok.
My question is: Are these x86/split lock detection errors directly causing the audio dropouts I’m experiencing? If so, would adding the kernel boot parameter split_lock_detect=off be the primary fix to try?
Would definitely make sense. Old code that has not been optimized for modern multi-core processors and of course sloppy & outdated programming can cause these “split locks”, which is why this detection was also built into the kernel. This is absolutely essential for critical infrastructure, where a microsecond costs money. For developers, this is a signal for: “Hey, take care of your code!” If you deactivate this, you can minimize the lags caused by the split lock, as no detection is active here, but you won’t eliminate it.
I’ve been seeing this outburst of x86/split lock detection in my journalctl output as well and I ahven’t been having audio issues, I think it might be a separate unrelated bug.
I am on 6.15.2 as well so maybe it was an issue with that kernel version. I’ve also had some amdgpu hard crashes.
A split lock is any atomic operation whose operand crosses two cache lines. Since the operand spans two cache lines and the operation must be atomic, the system locks the bus while the CPU accesses the two cache lines.
A bus lock is acquired through either split locked access to writeback (WB) memory or any locked access to non-WB memory. This is typically thousands of cycles slower than an atomic operation within a cache line. It also disrupts performance on other cores and brings the whole system to its knees.
26.2.1. #AC exception for split lock detection
Beginning with the Tremont Atom CPU split lock operations may raise an Alignment Check (#AC) exception when a split lock operation is attempted.
26.4. Usages
Detecting and handling bus lock may find usages in various areas:
It is critical for real time system designers who build consolidated real time systems. These systems run hard real time code on some cores and run “untrusted” user processes on other cores. The hard real time cannot afford to have any bus lock from the untrusted processes to hurt real time performance. To date the designers have been unable to deploy these solutions as they have no way to prevent the “untrusted” user code from generating split lock and bus lock to block the hard real time code to access memory during bus locking.
It’s also useful for general computing to prevent guests or user applications from slowing down the overall system by executing instructions with bus lock.
