Sammlung von Newsfeeds
The classic Serious Sam 2 gets a big upgrade and now Steam Deck Verified
DRAGON QUEST I & II HD-2D Remake out now and Steam Deck Playable
Running and streaming Duet Night Abyss on Linux: read this if OBS is causing lag
How I got the game, and the game capture, working without issue.
submitted by /u/sskg[link] [comments]
Is it true that Mesa Git has way better RT performance than current stable Mesa?
I have been trying to corroborate this but no clue about it. I have Bazzite so installing Mesa Git would be a mess. I am curious on how much (if) enhancement has been done in RT performance
submitted by /u/Joker28CR[link] [comments]
3D Games not Working on Linux (Mint Cinnamon 22.2)
Guys, the past days I've been trying to game on my Linux Mint notebook. It was Windows 11 previously and i could play those games very easily. The problems only happened in 3D games. All my drivers are updated (i have AMD processor with integrated graphic card), and i don't know what it could be.
I tried Stardew Valley, Don't Starve Together and Slay the Spire via Steam and all of them worked just fine, perfectly actually. When i tried to play Civilization VI and Hearts of Iron IV, they worked well on the initial menu, but when starting the game (or the 3D part of the game) it either just close the game (HOI4) or it crashes my entire PC (CIV). I tried looking at ProtonDB and testing different Steam Proton Versions but with no positive result.
The only way that i managed to play HOI4 was forcing the game to launch via OpenGL through the game launcher instead of using DX11 or 12, and it worked perfectly, i could play exactly like in windows. So i think the problem is making DirectX work.
Here is my Termbin link: https://termbin.com/jwxt
submitted by /u/pecorinosocks[link] [comments]
I'm having a crashing problem at the start of R.E.P.O.
When i click on steam to start playing the game a unity screen appears and after loading the entire bar this screen closes and the game crashes (without even starting or showing up)! How can i fix that?
I dont have a log folder in my .config to see what was the error that causes the crash.
submitted by /u/Capable-Republic-390[link] [comments]
FIX: Audio Crackles and Bugs out in Proton-based games and other games utilizing pipewire-pulse on Intel Chips (xruns)
I have been sitting on this for about 5 hours now, and after many misguided approaches, I finally found the solution to my problem and feel as if this should be more readily available for new people who might run into the same issue.
First off, I'd like to describe the issue I was (and you are likely) facing:
Whenever I played games using proton, my audio was garbled. Some games had it less predictable, i. e. KovaaK's, which would randomly blast distortion into my ear canals every few minutes when it felt like it. Other games were more predictable.
My savior in this case was Dispatch, I was able to recreate the Issue Every single time I pressed Esc.
!!!Before you try to follow this guide, ensure you are in the same or similar situation as I was. You shouldn't have to follow 3 different forum posts and end up with 3 new changes to .conf files and no solution found!!!The situation at hand was:
- I was experiencing xruns, which overwhelmed my cpu and caused garbled audio
- To Check if you're experiencing xruns, try to recreate the issue (like playing Dispatch and pressing Esc) whilst running pw-top on your Terminal! If one of your Outputs or modules in your filter chains report a number higher than zero in the "ERR" Tab, then an xrun has occurred.
- I am on an Intel CPU, namely one with E-Cores and P-Cores. This is important.
- I had already done some things like set my rtprio limit to 95 (To verify use ulimit -r) and my pipewire worker thread were running with realtime priority.
- To Check if your workers are running with rt priority, open up your terminal and type in ps -eLo rtprio,psr,cmd | grep pipewire. What should return is something like:
- - 0 /usr/bin/pipewire
- 95 0 /usr/bin/pipewire
- - 2 /usr/bin/pipewire-pulse
- 95 0 /usr/bin/pipewire-pulse
- - 14 grep --color=auto pipewire
- The Dashes mean the thread is not running in realtime mode. The number 95 (Or any number for that matter) means the thread is running in realtime mode.
I'd count all the following things as soft-requirements as I think these issues could still surface for people without them present:
- I was and still am using a filter chain on my Pipewire setup, namely a VSS-HeSuVi module and a Spatializer module. Both .confs are included in the linked wiki article.
- I did not experience these issues on native games like CS2 or Minecraft. Minecraft had its own audio issues, but these went away after I upped my ulimit -r to 95.
- My Kernel version is 6.17.5-arch1-1 with Kde Plasma 6.5.1.
- I'm Using the Proton Experimental version from 01-11-2025.
Why this issue is happening:
The CPU is overwhelmed by the amount of processing power required to convert the audio from my game (Dispatch) to my sofa-spatializer sound, to virtual surround sound and back to normal stereo output in realtime.
My theory is that the extra sound that comes from the pause menu popup in my case overran my buffer and thus created the distortion in the audio.
Now, you might think to yourself that modern CPUs like my Intel i5 13400F should be able to handle this. And you're right: The audio isn't distorted on native applications using pipewire without the pulse-compatibility layer.
If we go back to our previous command from above and type in ps -eLo rtprio,psr,cmd | grep pipewire, we see that there is another number next to our rtprio, the psr value.
This number tells us which thread the task is running on. On my output you see the worker threads are both running on thread 0, which means the first thread of my P-Core.
If you type this command in on your own machine and there is a number like 12 or 9 you have your workers running on either your Hyperthreads which are slower than your P-Threads or your E-Threads which are the worst of the lot. Your Threads have less processing power the higher your thread number is, where in my case thread 0-5 are my full performance P-Threads, threads 6-11 are my Hyperthreads and my threads 12-15 are my E-Threads. Your lower performance threads cannot handle the workload they're subjected to, so to fix this issue you have to pin these workers to your P-Threads.
How to fix the issueI wouldn't recommend skipping to this step without reading the rest so you can understand why this issue happens in the first place, but to fix the issue we need to pin our pipewire worker threads to our designated Performance Cores.
Also, if you haven't already, make sure to do all your changes in ~/.config/pipewire/ instead of /usr/share/pipewire. It's cleaner and safer.
To achieve this, you need to edit the .service files for pipewire-pulse (and pipewire to ensure this won't happen on games using pipewire). Open your terminal and enter:
systemctl --user edit pipewire.serviceThis will open up a Buffer file that should look like this:
### Editing ~/.config/systemd/user/pipewire.service.d/override.conf ### Anything between here and the comment below will become the contents of the drop-in file ### Edits below this comment will be discarded ### /usr/lib/systemd/user/pipewire.service # [Unit] # Description=PipeWire Multimedia Service # # # We require pipewire.socket to be active before starting the daemon, because # # while it is possible to use the service without the socket, it is not clear # # why it would be desirable. # # # # A user installing pipewire and doing `systemctl --user start pipewire` # # will not get the socket started, which might be confusing and problematic if # # the server is to be restarted later on, as the client autospawn feature # # might kick in. Also, a start of the socket unit will fail, adding to the # # confusion. # # # # After=pipewire.socket is not needed, as it is already implicit in the # # socket-service relationship, see systemd.socket(5). # Requires=pipewire.socket dbus.service # ConditionUser=!root # # [Service] # LockPersonality=yes # MemoryDenyWriteExecute=yes # NoNewPrivileges=yes # SystemCallArchitectures=native # SystemCallFilter=@system-service mincore # Type=simple # ExecStart=/usr/bin/pipewire # Restart=on-failure # Slice=session.slice # # [Install] # Also=pipewire.socket # WantedBy=default.targetIn the designated area, enter the following lines:
[Service] CPUAffinity=0-5The maximum number of 5 is set for my intel i5. On Chips with more or less P-Cores, this number will differ and you'll have to change it yourself.
Repeat this step with both services (pipewire and pipewire-pulse) to ensure this issue doesn't occur on any software using either.
I recommend rebooting to make sure these changes apply properly!
This isn't everything. To fully get rid of the xruns, you will also have to adjust your buffer quantum sizes. For me, leaving the default quantum in pipewire.conf as is was fine and I had to change my quantum size in pipewire-pulse.conf from 128 to 384. That truly got rid of the issue. If you're still experiencing the issue with a quantum of 384, try setting it to 96000 and see if the issue still persists. If it doesn't, then quantum sizes are not the cause. MAKE SURE TO RESTART YOUR DRIVERS AFTER EVERY CHANGE TO THE QUANTUM SIZES!
systemctl --user restart wireplumber pipewire pipewire-pulse
To minimize latency, try to find the lowest quantum size possible that doesn't cause xruns, however were talking about tenths of milliseconds here.
I am NOT an expert on linux systems. If there is a more elegant fix for this feel free to tell me.
submitted by /u/elyr1um[link] [comments]
Linux fixed my unsolvable shader stutters
Just to start off I've pretty much always been a windows user and never even thought of using Linux because I thought it would be "too hard" or "too much work". I have an AMD gpu and I've kinda always had these shader stutters that just wouldn't go away and would make gaming frustrating. I could minimize them or make them less frequent but they were always there. I would spend hours trying to find a new fix or something to get it to go away, I ended up reinstalling windows 10 probably 4-5 times and even "upgraded" to windows 11 even tho I hated it. I would pretty much always have issues with games. Games like Elden ring, Sea of Thieves, and Borderlands 3 were the worst. I have around 200-300 hours on Elden Ring and 100-150 on Sea of Thieves and around 10-20 on Borderlands 3 because it was just so unplayable. I really enjoyed these games but just couldn't fix these annoying stutters and just tried to get used to it. It wasn't until I decided to be ballsy and just say f*** it and put arch linux on a usb drive and tell myself to figure it out (had no idea what i was doing so i watched a video). At first I thought everything felt snappy just because its a fresh installation of an OS, but as I kept installing more and more programs I was amazed at how snappy everything remained. I then decided to install a few games and decided to start off with Sea of Thieves. I genuinely thought my game was bugged when mangohud said I had 240 fps on max settings with like 90% gpu usage and 5-10% cpu usage. I genuinely believed something had to be wrong with my game because I have never seen that high of a number in that game. After multiple windows installations and resets I never saw frames that high in Sea of Thieves, the most fps I've gotten in that game is like 120. Then I walked around and I did not encounter a SINGLE stutter. Not one single stutter. I thought that maybe they fixed the game so I reinstalled Elden Ring and Borderlands 3. Elden Ring also ran flawlessy. My 7900xtx was crusing at like 30-40% usage max settings (no ray tracing) without a single stutter. I also booted up Borderlands 3 which is known for very bad optimization and that game ran surprisingly well. I saw a few stutters here and there but it was NOTHING compared to what it used to run like. This whole Linux gaming experience has been wonderful and I look forward to playing more games on Linux. After experiencing Linux for the past week or so I'm confident to say I never want to go back to windows. Seeing sub 10% cpu usage on games and knowin that my computer Isn't running random bullshit in the background to cause my games to lag is amazing. Also i noticed my CPU runs cooler since there's basically nothing running in the background.
TL;DR
I've always been a windows user and experience lots of shader stutters and unexplainable stutters in games so I made a ballsy move and switched to Linux Arch for my first time using Linux and it fixed all my stutters in games and even got fps boosts.
submitted by /u/Best-Mix-8037[link] [comments]
Seiten
- « erste Seite
- ‹ vorherige Seite
- …
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
