Jerkying gameplay...

[caku]

I'm running Wesnoth version 1.8.4 (Italian) on OpenSuSE 11.3 and I've problem of jerking gameplay.

When I start the application, at the first screen where you can choice "campaign", "multiplayer", "preference" etc... there isn't problem, but when I go in the campaign screen to choice the adventure to play and also during the gameplay the audio, the mouse arrow and the gameplay screens start to work jerking.

Starting the game from the console I receive the same message for many times:
ALSA lib pcm.c:7245:(snd_pcm_recover) underrun occured

I've tried to reduce the audio frequency (from "preference > audio > advanced") from 44kHz to 22kHz and the audio seems to work well, the mouse arrow and the gameplay screens jerk a little bit less and from the console I don't have any error message, but the game is not playable anyway.

I wait for an answer.... I love this game!
Thanks
Luca

[Pentarctagon]

just fyi for any future posts/threads: capitalizing entire words in the thread title is unnecessary, as is bolding/underlining words as often as you did.

[Iris]

I for one don't have a good answer for this problem (other than what Pentarctagon mentioned above), but FWIW:

ALSA lib pcm.c:7245:(snd_pcm_recover) underrun occured

I see this line very often in the stderr output for Wesnoth 1.8.x and 1.9.x on Debian Squeeze (+Sid+Experimental) here, but it doesn't cause any problems with gameplay, and in fact, I can still hear sound effects and user interface feedback without lag or other issues — I don't know about music though, since I don't play with the in-game music enabled. In my case I'm also using the ALSA-backed SDL libraries instead of PulseAudio or other intermediaries.

[vcap]

I would try to disable the music entirely and see if it makes a difference. Also is this just wesnoth or do you have problem in other games (especially other sdl games)?

The content of /proc/interrupts may be relevant (that's "cat /proc/interrupts" in a terminal), as is the output of "lspci -v". Also, is there anything special running in the background (top and powertop, can help here).

In my case I'm also using the ALSA-backed SDL libraries instead of PulseAudio or other intermediaries.

How do you do that on a case-by-case basis? some SDL_* environment variable? or is this just how your system is configured globally.

Anyway it may not be enough since, for all i know, alsa can be configured to forward to PulseAudio. So, an extra step may be needed to get direct alsa to hardware. (this is all guesswork btw, none of my systems have pulseaudio in the first place).

[Iris]

In my case I'm also using the ALSA-backed SDL libraries instead of PulseAudio or other intermediaries.

How do you do that on a case-by-case basis? some SDL_* environment variable? or is this just how your system is configured globally.

Anyway it may not be enough since, for all i know, alsa can be configured to forward to PulseAudio. So, an extra step may be needed to get direct alsa to hardware. (this is all guesswork btw, none of my systems have pulseaudio in the first place).

My bad, I actually have the SDL build with support for all sound backends installed (libsdl1.2debian-all) instead of the ALSA-only build (libsdl1.2debian-alsa). The trick here is that I don't have PA installed at all.

[vcap]

There is a docs/html/sdlenvvars.html in the SDL sources that says that you can force the audio backend by setting the SDL_AUDIODRIVER environment variable. So, to hand over audio to alsa something like this should do:

Code: Select all

SDL_AUDIODRIVER=alsa wesnoth

What alsa then do is up to it and how it is configured on OpenSuSE.

EDIT:
I am not convinced that PulseAudio is the culprit, however.

While PulseAudio can certainly affect audio latency, i don't think it would affect so badly the latency of the whole system, including the servicing of mouse interrupts, like seems to be the case here. That's why is suspect a problem with either shared interrupts (/proc/interrupts will tell, that's when you have a lot of unrelated devices lumped on the same line, in the right-most column), or a device hogging the pci bus (you don't want a device that is both throughput-heavy and has too high a value given for latency in the lspci -v output). Or maybe just a process in the background monopolizing the cpu (even though the process scheduler in the kernel is supposed to prevent this).

[Vladimir]

Hello! I have solved this problem by setting audio sampling frequency to my soundcard's native 48 kHz instead of default 44,1 kHz in the game settings menu.
Game was run on notebook with Pentium-M 1,7 GHz, 0,5 GB RAM, with Intel integrated soundcard, OS is Ubuntu-oneiric with pure ALSA. Now everything - sound and image is fine.

[Iris]

I can’t really confirm whether it fixes the problem for me or not (I also use an onboard Intel sound controller now, although when I first posted in this topic I was using a different laptop with an AMD controller, and in neither case I’ve had any symptoms other than the stderr messages), but changing the sample rate to 48 kHz completely distorts the game’s music, which is stored in 44 kHz format and (to my knowledge) never resampled at runtime.