The online racing simulator
Linux 0.6H Stuttering
(17 posts, started )
#1 - mr_spoon
Linux 0.6H Stuttering
Hi,

Thanks Scavier muchly for 0.6H, WestHill new track is great & its fun to have a new track to play with! Thumbs up

I'm just wondering if anyone else using Wine on Linux to play LFS using the latest 0.6H release has noticed any momentary sound+graphic pauses when playing it? I've not investigated much yet, but just wondering if anyone else had as I haven't encountered this before. I last played LFS around Christmas and never had this issue. I'll check if other tracks do this later as I'm wildly guessing it might be related to the paths that Westhill has?, but that's an utter random guess!
#2 - StickyBranches
Well, on wine there are FPS drops but I haven't experienced any sudden sound pauses. 0.6H imo runs very good compared to the older versions as they were nearly unplayable!
#3 - mr_spoon
Just a quick reply for reference; I tried another track & had the same issue so it is nothing to do with the new track. I tried disabling Vsync and other things (alternative shadows, framerate cap) but will play around further.
#4 - Dygear
I've not had that issue using wine on the Mac, the last time I used wine on Linux I had a simmilar problem and it was due to an older driver that was hanging up every now and again. So check your driver stack first.

You should also post your hardware specs and the drivers that you are using for your sound card and video card.
#5 - mr_spoon
Hi Dygear, thanks for your reply, good idea about the drivers.

I've just updated to the latest nVidia blob drivers & same issue. I tried playing networked & not networked, to see if it was network-related, as I thought my new fibre internet router might be to blame, but no change. For sound I use SPDIF out of ALC892 sound chipset on motherboard but don't fancy messing with it. Debian Jessie should be released in the next week or two, I might just wait and move over to that from Slackware & see if it fixes the issue.
#6 - mr_spoon
Just found that the issue is related to having force-feedback enabled. I noticed the glitching didn't happen if I was driving with the menu over the screen & also noticed FFB was disabled at this point. Wine/Linux must have issues with FFB in some way as with it disabled the glitching goes away. I tried a few setting within LFS regarding FPS limit & VSync etc. but they didn't fix it.

I'm just mentioning it for reference really. Not looked into it any further yet.

Note other person here also encountering it.

I'm using: wine-1.8-rc4 (Staging), on Debian Jessie.
#7 - felplacerad
Michalxo ("other person") had/is having the issue in RBR as well as LFS.

In what way did you disable FFB? In LFS or in Linux?
#8 - mr_spoon
I disabled it in LFS itself; Options > Controls > Axes/FF > ForceFeedback=no.

It isn't a solution as such as playing without FFB isn't any fun.
#9 - Michalxo
If FFB is it the issue, than it seems like it is pure g25 driver problem to me. It would make sense.

I have not played LFS/RBR since reporting and getting tired of issue. I will have a look at it in 10 days, when I will come back to G25.
Merry Christmas Smile
#10 - MadCatX
Quote from Michalxo :If FFB is it the issue, than it seems like it is pure g25 driver problem to me. It would make sense.

Not necessarily. The problem can be anywhere deeper down the way in the HID or USB stack. The lg4ff driver is rather simple and although it does grab two spinlocks since kernel 4.2, it cannot really make an userspace application stuck unless there is concurrent write access to the wheel. The only way how to get this on a G25 would be by constantly changing the range through sysfs and playing some FFB effects. It would also show up in strace as write() or ioctl() calls on the wheel's file descriptor taking a long time.
#11 - mr_spoon
I've also tried:
- USB 2 port on my PC rather than the USB 3 one, no difference.
- Running from SSD (that OS exists on) rather than secondary HDD, no difference.
#12 - mr_spoon
I've run it with strace (strace -tt -o strace_output_wheel.txt wine LFS.exe) noted it glitch and glanced at my watch that I'd synced to my PC at 16:18:30, so about then or a second or 2 before. I've had a look through the output and see a few possibly interesting messages. This section looks a little different to the others:
16:18:29.465939 writev(18, [{"&\2\2\0\324\1\0\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
16:18:29.465982 poll([{fd=18, events=POLLIN}], 1, 4294967295) = 1 ([{fd=18, revents=POLLIN}])
16:18:29.466012 recvmsg(18, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\277\1\0\0\0\0\324\1\0\0\1\0 \5w\2\5\2w\2\5\2\20\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
16:18:29.466049 recvmsg(18, 0x32f684, 0) = -1 EAGAIN (Resource temporarily unavailable)
16:18:29.466070 recvmsg(18, 0x32f684, 0) = -1 EAGAIN (Resource temporarily unavailable)
16:18:29.466084 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
16:18:29.466099 write(3, "\242\0\0\0\0\0\0\0\374\1\0\0>\0\3\0w\2\0\0\5\2\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466115 read(5, "\0\0\0\0\4\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466130 read(5, ">\0\3\0", 4) = 4
16:18:29.466145 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16:18:29.466160 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
16:18:29.466174 write(3, "\321\0\0\0\0\0\0\0\6\2\0\0\4\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466189 read(5, "\0\0\0\0<\0\0\0Z\0\5\0\0\0\0\0\0\0\0\0\1\0\0\0\300\3\1\0\0\0\0\0"..., 64) = 64
16:18:29.466202 read(5, "C\0:\0\\\0w\0i\0n\0d\0o\0w\0s\0\\\0s\0y\0s\0t\0e\0"..., 60) = 60
16:18:29.466216 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16:18:29.466235 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
16:18:29.466254 write(3, "\323\0\0\0\0\0\0\0\6\2\0\0Z\0\5\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466269 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466283 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16:18:29.466299 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
16:18:29.466313 write(3, "\322\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466328 read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466342 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16:18:29.466358 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
16:18:29.466372 write(3, "\206\0\0\0\0\0\0\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0"..., 64) = 64
16:18:29.466387 read(5, "\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
16:18:29.466410 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
16:18:29.466423 clock_gettime(CLOCK_MONOTONIC_RAW, {17203, 335054391}) = 0
16:18:29.466438 recvmsg(18, 0x32f7e4, 0) = -1 EAGAIN (Resource temporarily unavailable)
16:18:29.466453 recvmsg(18, 0x32f7c4, 0) = -1 EAGAIN (Resource temporarily unavailable)
16:18:29.466468 recvmsg(10, 0x32f7e4, 0) = -1 EAGAIN (Resource temporarily unavailable)
16:18:29.466481 sched_yield() = 0
16:18:29.466494 clock_gettime(CLOCK_MONOTONIC_RAW, {17203, 335125492}) = 0
16:18:29.466508 poll([{fd=39, events=POLLIN}], 1, 0) = 0 (Timeout)
16:18:29.466523 poll([{fd=39, events=POLLIN}], 1, 0) = 0 (Timeout)
16:18:29.466537 poll([{fd=40, events=POLLIN}], 1, 0) = 0 (Timeout)
16:18:29.466551 poll([{fd=40, events=POLLIN}], 1, 0) = 0 (Timeout)

As it repeats the lines ending '32' & '64' more than usual.

I've attached a shortened extract of the strace output if anyone else can make more sense of it? Smile

I also noticed the console was outputting the following message whilst LFS was running:
fixme:dinput:joy_polldev joystick cannot handle type 21 event (code 0)

I tried to use my brother's MOMO wheel to see if the problem persisted, but it didn't work correctly at all so possibly doesn't even have decent drivers in Linux as it is older & probably less popular than my G25.
Attached files
strace_output_wheel-161830-short.txt.zip - 882.4 KB - 322 views
#13 - mr_spoon
Righto, I think I've stumbled upon a solution; running LFS from the GUI, i.e. clicking on the LFS.exe icon to launch it results in the glitchy behaviour. Running LFS.exe from the command line does not!

Yay!

Big grin
#14 - mr_spoon
Yup this definately fixed it for me. I've run multiple times LFS from the command line vs running by double-clicking LFS.exe & the former eliminates the glitching.

Note: it is still possible to make an icon shortcut to run the game but in advanced settings I must set 'Run in terminal'. I am using KDE v4.14.2 desktop, other desktops may be different.

Edit: the problem with launching by simply double-clicking the LFS.exe might be caused by Wine/KDE trying to display some sort of FFB-related desktop notifications in the background?
#15 - MadCatX
These are pretty strange results. I couldn't find any traces of stuttering in the strace log, there is only one little spike that seems to be done intentionally by WINE. As long as you can reliably reproduce it it might be interesting to ask around WINE devs mailing lists about this. MOMO uses the same lg4ff driver as G25 so I find it odd that it wouldn't work.
#16 - felplacerad
So that disabling FFB from within LFS solved the problem was a false positive?

Edit: Oh, I read your post too quickly. I see now that you pointed out a potential relation between the FFB setting and whether LFS was launched from a terminal or the desktop shortcut (without the 'Run in terminal' option enabled.
#17 - mr_spoon
Has the above fixed this for anyone else too, or is it just my setup? Is anyone running Gnome desktop that can test if it behaves similarly?

I'll post up to the Wine user mailing list after a bit more testing things, i.e. does playing LFS in windowed-mode behave differently?

Linux 0.6H Stuttering
(17 posts, started )
FGED GREDG RDFGDR GSFDG