Generic Linux Kernel Causes Input Lag, Delayed Audio Playback, Choppy and Distorted Audio

[mmstick]

The problem:

• The generic kernel is too high in latency for gaming.
• The latency issue is causing a lot of input lag and framerate latency.
• It is also causing a lot of buffer underrun/overrun and audio latency issues.

The solution:

• Replace the kernel with a low latency kernel, which has solved all of my issues with audio latency, choppy and distorted audio, and finally input lag.

For Ubuntu, instead of having to compile the kernel yourself, you can install a low latency kernel from KXStudio developers (supports Lucid (10.04) all the way to Saucy (13.10)).

sudo add-apt-repository ppa:kxstudio-team/kernel -y; sudo apt-get install linux-lowlatency -y

Reboot and select the lowlatency kernel manually in grub (if it is not already the default kernel).

[gdrewb-valve]

Not a Steam issue then, this is just informational? Leaving for others.

[synergydev]

On a lot of hardware this doesn't solve the issue. I've tried multiple kernels, and also tested my personal kernel with Colin Kolivas' interactivity benchmark and my score reflected perfect interactivity. I've also tried the following combinations: -bfq, bfqio, bfs. -cfq, cfqio, cfs. -deadline (no cfqio), cfs. -Deadline, no cfqio, bfs. -Sio, no cfqio, cfs.

Aside from the lowlatency kernel listed, all scheduler testing was done on a custom mainline (3.10-rc4) kernel built for low latency, preemptible desktops with tick rate set to 1000Hz. Also using the performance governor (no cpu scaling), and respectively no gpu scaling on all three cards. I've also attempted to directly launch games using schedtool to try and achieve greater gaming interactivity. I've even attempted to forcibly disable SMP support completely and only utilize one core of my six core processor. While the kernel hack did work for only utilizing one core, the end result with steam linux was still the same.

I would consider this a steam issue since wine gaming is still flawless, as well as virtualbox gaming if you have properly setup virtualization with the direct gpu patch (can't comment on AMD). I've also tested steam for linux on a dual 8800gtx system with the latest proprietary nvidia beta drivers (don't remember the version, but the latest as of writing this), as well as an ATI 7970 with the 13.6 beta catalyst drivers.

I've tested Portal, Team Fortress 2, Left 4 Dead, and Counter Strike: Source. I get very good FPS in all games as expected. Interestingly, Counter Strike Source doesn't consistently have the input lag. It comes and goes, yet the fps stays consistently maxed out. I've also read of a "fps_max" workaround which has no effect. I found a very old wine bug that was similar, and also found reports for this steam linux bug going back four months. Perhaps there's a FOSS gaming project that has run into a similar issue in their project that could be of assistance? It's a real shame since many users have known that steam linux is absolutely unusable for the past four months, yet from the discussions it doesn't appear as much (public) headway has been made into this issue.

Until Steam Linux is usable, it might be better to post instructions on the steam site for running Steam in Wine opposed to users downloading their games before realizing the project is unusable. Or at least put a disclaimer on the Steam site.

Hope this gets worked out.

[mmstick]

Your problem can be traced back primarily to proprietary drivers, especially on the AMD side. As for 79xx or 7xxx in general, yes there's still a ton of input lag in specific titles (I can't get TF2 playable in online servers but offline servers full of 24 bots are okay). Kernel latency has nothing to do with the issues we have here, but there's also not much we can do about it until something is done by the lack of care in driver development for Linux. I've heard running the open source drivers will yield much smoother and consistent framerates, even if you get less framerates than closed source drivers. However, you can't use open source drivers with Radeon HD 7xxx yet because it's broken still.

There is, yes, some issues with the implementation of Source engine on Linux still, and to an extent may be linked with graphics driver issues I assume. Games do run better in wine since wine developers have more than likely already figured out workarounds for a lot of issues with graphics drivers and the like.

If Steam is to have a disclaimer for Linux, it's going to need a pretty long disclaimer on common issues, solutions, known bugs, etc.

Something I don't really understand is why the proprietary drivers aren't able to just copy all the open source code and simply add on their patented features on top so proprietary can benefit from the best of both worlds.

[synergydev]

Based on this response, I'm a little lost as to the accepted validity of the kernel workaround. However, I still don't understand how proprietary drivers are to blame since I haven't run into this issue on one non-steam for linux game. It would also stand to reason that if the proprietary drivers were to blame, at least one game I've tried in Wine or natively would have also had the issue (since we're still using the proprietary linux drivers in wine). I also get approximately the same input lag on the dual 8800gtx system as well as the amd 7970 system (yes, I know the AMD drivers are awful). With nouveau opposed to the proprietary nvidia drivers, the input lag seems to be a slightly less bad, but still quite bad for me - definitely unplayable (and yes I'm still getting consistently 60+FPS). I also can no longer run some games I have via wine at all such as Borderlands 2 and Far Cry 3 with nouveau. Unreal Tournament 3 ran, albeit far worse than the source games (probably due to the engine which is heavily tailored toward proprietary drivers, and a lot heavier).

If I understand correctly, these source games are using OpenGL on Linux. I tried the first two native Linux, OpenGL games that came to my mind which were Nexuiz and Urban Terror, and both played flawlessly. Is there some major difference between Steam (Source) for Linux titles and every other linux game I'm missing? Can you name a non-steam title that has these problems with proprietary drivers...or even open source drivers? If not, then it seems to be purely a Source for Linux issue.

Thanks.

[mmstick]

Didn't you read my comment?

"Games do run better in wine since wine developers have more than likely already figured out workarounds for a lot of issues with graphics drivers and the like."

Low latency kernel drastically improves responsiveness of the system regarding input lag and audio stuttering; this is well known. It improves all games, Wine and Source across the board. However, there are still some games that have issues with closed source drivers and general bugs in the Linux version; it's not as if it magically solves all problems.

I will, however, report that if you enable multicore threading in the source engine games through the console in-game, it helps with the input lag and framerate to an extent.

[synergydev]

I understand that. I guess I didn't notice a difference due to already having the patches used in that kernel. The strange thing is that nouveau doesn't really seem to help input lag on my re-evaluation of it. If it does, it'd too minimal to tell.

I'm wondering if the issue could be related to fullscreen not being handled correctly with these source games unlike other Linux games. That seems to be the main difference. If full screen is used in game, it can still be manipulated as a window, possibly affecting input latency? This is a stretch, I'm just trying to find a common thread here. I'm not using an additional compositor, just x with i3wm. Also tried DWM with the same issue.

[mmstick]

Do you use pulseaudio while gaming? That causes a fair amount of issue in itself. I don't know what causes the input latency but Valve would know how to find out considering they are experienced with performance analysis of this kind of stuff.

[V10lator]

A bit off topic, I know. Don't slap me:

Something I don't really understand is why the proprietary drivers aren't able to just copy all the open source code and simply add on their patented features on top so proprietary can benefit from the best of both worlds.

Licenses. The open source drivers are using API functions of the Linux kernel the proprietary ones are not allowed to use. But the whole compiled binary has to use the same license. Also they can't dual-license code they don't have all rights for but not every contributor is a employee.

BTT:

I'm wondering if the issue could be related to fullscreen not being handled correctly with these source games unlike other Linux games.

AFAIK that is handled by SDL 2. Now SDL 2 is relative new, so you need to find another game using it to confirm this. Brütal legend ships with it, so chances are high it uses it, too. But I guess you search a free game.

[mmstick]

Then we shall say, why not nullify those patents (or at least present amnesty to the open source community) and make the driver completely open source? What do they have to gain in keeping it secret? So far there's quite a lot to lose, at least for performance of their graphics card on Linux. It's very similar to patenting a mathematical equation, as I don't expect to see anything creative in a graphics technology patent.

[synergydev]

Back on topic: @mmstick, I use direct alsa hw output. @V10lator I'll check into sdl a bit, thank you. I saw there was a launch flag for fullscreen sdl that some guys were using to fix the issue, but no go for me on that either. I tried nexuiz in a window and got slight input lag much as these source games experience, making me believe that might indeed be part of the issue for many users.

[V10lator]

@mmstick Cause of lawyers. They tell you things like: "You can easily reverse-engineer the chip design when you have the driver sources / documentation". Ofc. this is bs, real live tells otherwise: We have open source Intel and AMD GPU drivers but nobody copied the GPUs (not to tell about all the other open source drivers). Another thing is third party code, that means code the company didn't write for them self but buied licenses from another one. Most of the time these license arguments forbid to re-license and/or handle that codes out to anybody other. Last how to be a good patent troll (here the lawyers are working again) without patents?

@synergydev Make sure to test another SDL 2 game as (IIRC) it uses a completely different mechanism for maximized windows than 1.X - The more I think about it the more I think it is a SDL issue. Do you have input lag with GoldSrc (like the original Half-Life) games, too? @slouken are you reading this? ;)

[mmstick]

Considering Google was able to grant amnesty to open source projects, AMD/NVIDIA should be able to do the same as well. If something isn't done about this very real problem, everyone will remain completely effed to the point where Intel will be considered a superior competitor in gaming graphics on Linux. I hear those open source Intel drivers run these source games smoothly.

I know I don't have input lag in Day of Defeat Source or Counter-Strike Source with my HD 7950 on fglrx; just when you get to more modern Source games like TF2.

[kernelOfTruth]

Realtime scheduling might help, but it's more of a thing for advanced users (and for those who have access to the root account)

Appending

threadirqs

to the kernel command line

and the following script might help:

#!/bin/bash

# Sorted view:
# ps -eLo rtprio,cls,pid,pri,nice,cmd | grep "FF" | sort -r

# ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"

# For a non-RT kernel, use kernel option: threadirqs

# http://subversion.ffado.org/wiki/IrqPriorities
# http://alsa.opensrc.org/Rtirq

#piwl=$(pgrep "irq/.*-iwlwifi")
#[[ -n $piwl ]] && chrt -f -p 10 $piwl

#peth=$(pgrep "irq/.*-eth0")
#[[ -n $peth ]] && chrt -f -p 30 $peth

#peth=$(pgrep "irq/.*-eth1")
#[[ -n $peth ]] && chrt -f -p 30 $peth

peth=$(pgrep "irq/.*-eth")
[[ -n $peth ]] && chrt -f -p 50 $peth

# ehci instead of uhci
pmouse=$(pgrep "irq/23-ehci")
[[ -n $pmouse ]] && chrt -f -p 59 $pmouse

pmouse=$(pgrep "irq/20-ehci")
[[ -n $pmouse ]] && chrt -f -p 59 $pmouse

#pmouse=$(pgrep "irq/19-uhci")
#[[ -n $pmouse ]] && chrt -f -p 59 $pmouse

psnd=$(pgrep "irq/.*-snd_hda")
[[ -n $psnd ]] && chrt -f -p 80 $psnd

#pnouveau=$(pgrep "irq/.*-nouveau")
#[[ -n $pnouveau ]] && chrt -f -p 80 $pnouveau

pnvkm=$(pgrep "irq/.*-nvkm")
[[ -n $pnvkm ]] && chrt -f -p 80 $pnvkm

#pkbd=$(pgrep "irq/.*-i8042")
## 2 of them
#for p in $pkbd ; do
#   chrt -f -p 60 $p
#done

prtc=$(pgrep "irq/.*-rtc0")
[[ -n $prtc ]] && chrt -f -p 90 $prtc

( while true ; do 
   # Does not have an IRQ until Xorg is running
   pnvidia=$(pgrep "irq/.*-nvidia")
   if [[ -n $pnvidia ]] ; then
      chrt -f -p 80 $pnvidia
      break
   fi
   sleep 20
done ) &

source: https://forums.gentoo.org/viewtopic-p-7153966.html#7153966

modify as needed