Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[Linux] Sound is played slightly delayed #45
Can't confirm if it's all sound that is played, but gunshots are played slightly too late.
Edit: The startup parameter "SDL_AUDIODRIVER=pulse" seems to be unnecessary since the last small update. (390298 › 391217)
I notice it too.
Version du système d'exploitation :
Carte graphique :
Carte son :
Logiciel installé :
Rapports d'échec récent :
I seem to have found a workaround:
Edit the /etc/pulse/daemon.conf and set the following values:
Don't forget to remove the comments (";") in those lines.
Seeing the previous commenter using Arch Linux as well, this is possibly not an issue on other distributions.
Please provide feedback if this fixes the issue if you experienced sound delay.
@robled This workaround reduces the size of your audio buffer. Too low values can cause sound glitches like your popping. The lowest value you can use without glitches is completely dependant on your sound card, so I guess you could try a little higher values and see if it works.
Sorry for bumping old thread, but pulseaudio is known to increase latency on each audio underrun (which isn't uncommon with CPU hungry game), either you give PA realtime priorities (so audio will get priority over game itself), or PA will be increasing latencies step-by-step as long as the game can't fill the buffer quickly enough.
There is no workaround AFAIK, either stop using pulseaudio or restart PA daemon from time to time so latencies get back to normal (you will have to reset game or go into settings and set some different audio configuration (2speakers -> 5.1 -> 2speakers) to fix.
You can try running 'pulseaudio -k && pulseaudio -vvvv' in console and then watch the PA output as you play to see wheater you are affected by this thing or not.
Anyways, this will afect you even if you set
default-fragments = 5
By the way, this is quite absurd setting, extremely CPU hogging (CPU scheduler runs at 1000Hz on most desktops and fragment size 2msec would force every other scheduler cycle to handle audio code, having half of one core busy with audio is probably not what you really want (and if it is, you should use rt-linux kernel and increase default-fragments to higher value).