Osu: Better Linux timing

[stevefan1999-personal]

I noticed that although I clicked at the right time (according to rhythm), the game still registers my hit as most of the time 100/50 but not miss. So it must be either the audio latency or input latency since I have a 144Hz monitor and >400fps in-game. I'm using Manjaro. The audio timing is pretty random (that I had random acc) so audio offset didn't really help much (I had a +-3 ms window personally), maybe it is due PulseAudio server not processing within the time window?

[peppy]

Are you visually seeing jumps or something? All timing is done in a way such that audio drivers should not affect it. If setting an offset isn’t helping you, I’d argue it may be your perception. Have you tried turning on autoplay and listening to hitsounds? If they sound correct, then we can rule out an issue with actually timing being wrong (at which point it’s either input or user related).

[WebFreak001]

I used to have around up to 200ms audio delay with pulse on manjaro, changing the pulse config like this fixed it for me: https://ludwig.im/en/projects/steam-pulseaudio-sound-latency-lagging-problem-noise#optimize-pulseaudio-settings-for-steam-games

(this was the fix on manjaro)

[stevefan1999-personal]

I have "benchmarked" kernel latency:

hwlatdetect:  test duration 120 seconds                                                                                                                                                                                                         │···························
   detector: tracer                                                                                                                                                                                                                             │···························
   parameters:                                                                                                                                                                                                                                  │···························
        Latency threshold: 15us                                                                                                                                                                                                                 │···························
        Sample window:     1000000us                                                                                                                                                                                                            │···························
        Sample width:      500000us                                                                                                                                                                                                             │···························
     Non-sampling period:  500000us                                                                                                                                                                                                             │···························
        Output File:       None                                                                                                                                                                                                                 │···························
                                                                                                                                                                                                                                                │···························
Starting test                                                                                                                                                                                                                                   │···························
test finished                                                                                                                                                                                                                                   │···························
Max Latency: 18us                                                                                                                                                                                                                               │···························
Samples recorded: 23                                                                                                                                                                                                                            │···························
Samples exceeding threshold: 23                                                                                                                                                                                                                 │···························
ts: 1543752652.046263305, inner:14, outer:16                                                                                                                                                                                                    │···························
ts: 1543752653.062968993, inner:14, outer:16                                                                                                                                                                                                    │···························
ts: 1543752666.236269250, inner:18, outer:14                                                                                                                                                                                                    │···························
ts: 1543752669.276275592, inner:13, outer:16                                                                                                                                                                                                    │···························
ts: 1543752670.289599359, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752677.383011476, inner:16, outer:13                                                                                                                                                                                                    │···························
ts: 1543752680.423017294, inner:13, outer:16                                                                                                                                                                                                    │···························
ts: 1543752687.516287288, inner:16, outer:15                                                                                                                                                                                                    │···························
ts: 1543752689.543020338, inner:14, outer:16                                                                                                                                                                                                    │···························
ts: 1543752692.582996183, inner:14, outer:17                                                                                                                                                                                                    │···························
ts: 1543752694.612927483, inner:16, outer:15                                                                                                                                                                                                    │···························
ts: 1543752695.622962007, inner:13, outer:16                                                                                                                                                                                                    │···························
ts: 1543752698.662942253, inner:16, outer:15                                                                                                                                                                                                    │···························
ts: 1543752700.689631856, inner:13, outer:16                                                                                                                                                                                                    │···························
ts: 1543752701.702992867, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752704.743009018, inner:16, outer:15                                                                                                                                                                                                    │···························
ts: 1543752707.783008794, inner:16, outer:15                                                                                                                                                                                                    │···························
ts: 1543752714.876280049, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752716.902964719, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752718.929591837, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752751.356248716, inner:15, outer:16                                                                                                                                                                                                    │···························
ts: 1543752755.412983987, inner:13, outer:16                                                                                                                                                                                                    │···························
ts: 1543752762.502939391, inner:16, outer:13

So kernel latency is pretty consistent, not a correlated variable here.

[peppy]

This doesn't answer any of my questions though. Could you provide a video of what you're seeing? Could you answer my other questions?

[stevefan1999-personal]

@peppy It's not a breeze to setup video recording on Linux, let alone It wouldn't work since the framerate will be downscaled.
However I did try to see if AM works on Freedom DIve, but I couldn't trust the result because it is not hitting perfectly on 0:33 so it is a contradiction. I could try to use editor recordings too see if it respect audio offsets and my perception, does it respect?
For actual game play, uh, I'm not a good player so unless necessary I wouldn't want to publicly shame myself...

[peppy]

Are you able to take a recording of your screen using your phone? Might be easier to discern what the issue is this way.

[ghost]

@peppy
I'm facing the same problem.
It's hard to tuning audio offset without wizard.

I have took two videos:

On the osu! main screen: https://www.dropbox.com/s/4e71vmoikdgmnsl/2018-12-19%2010.54.42.mp4?dl=0
Game autoplay: https://www.dropbox.com/s/1riw7vmcf24f6jl/2018-12-19%2011.01.42.mp4?dl=0

The song is BPM 120, maybe it helps when you need to analyze the video

[ghost]

I have checked that the timing of the beats is correct. But the hitsounds is wrong.

[Dumpling97]

Same issue on Ubuntu 18.04 here. But I believe it is the audio latency since I can get almost normal accuracy with +50ms offset.
Audio subsystem (lspci -v | grep -A7 -i "audio") : Fujitsu Limited. Sun Rise Point-LP HD Audio

[peppy]

Could you please state what audio subsystem you are using for linux caes?

[Ferdi265]

@Dumpling97 that is your audio hardware, not the audio subsystem used. Subsystem is usually PulseAudio on modern Linux distros (you can verify this using ps aux | grep pulseaudio) or just plain ALSA if PulseAudio is not used. Some more exotic setups use JACK, but I know no place where that is default.

[ArniDagur]

My in-game accuracy when using Wine is a lot higher than on osu!lazer, no matter what offset I try.

[Yutsuten]

I'm having exactly the same problem as @BinotaLIU on Debian 9 here...
For now playing with effects volume on 0.

$ ps aux | grep pulseaudio
Debian-+   956  0.0  0.1 1160984 11536 ?       Ssl  15:15   0:04 /usr/bin/pulseaudio --daemonize=no
mateus    1398  1.6  0.2 2740532 20836 ?       S<l  15:16   2:30 /usr/bin/pulseaudio --start --log-target=syslog
mateus    8093  0.0  0.0  13804  1012 pts/3    S+   17:44   0:00 grep pulseaudio

[Yutsuten]

After reading a little about pulseaudio here, here, here, here and its documentation, I was able to fix the issue by changing the pulseaudio configuration.

I tested a lot of different configurations, but the one that worked the best for me was to enable this option that is disabled by default.

_fixed_latency_range
Since 2.0. Boolean. Normally when there's an alsa underrun, and timer based scheduling is used, the alsa sink will raise the minimum latency that applications can get to avoid further underruns. If this option is enabled, the minimum latency will stay constant even if underruns occur._

Edit the file /etc/pulse/default.pa on the line that has

load-module module-udev-detect

to

load-module module-udev-detect fixed_latency_range=yes

Restart your PC. Or you can kill and restart pulseaudio with pulseaudio -k && pulseaudio --start.

To check my latency, I often used the following command:

pactl list sinks | grep Latency

Before the change, it outputted about 90000 usec (90 ms), but after the change it rarely passes 10000 usec (10 ms) while playing osu!.

Hope it helps!

[ArniDagur]

@Yutsuten I think that fixed it for me. You're a legend.

[peppy]

This leads me to think that the bass buffer may be too low, causing the underrun scenario mentioned in that documentation. If you have osu! in a compileable state (you will need a local framework checkout), please try adjusting the values in AudioManager

PlaybackBufferLength = 500 (or 1000)

and possibly experiment with UpdatePeriod, though I think the above is more likely the culprit.

[Yutsuten]

I tried changing PlaybackBufferLength and UpdatePeriod, but I didn't notice any difference...

This is all the data I collected this time (also got some data from Rhythmbox and Firefox as I was curious about how fixed_latency_range influences them).

---

• With load-module module-udev-detect fixed_latency_range=yes

# Rhythmbox
$ pactl list sinks | grep Latency
        Latency: 89463 usec, configured 90000 usec

# Firefox - Youtube
$ pactl list sinks | grep Latency
        Latency: 22919 usec, configured 25000 usec

# osu!
$ pactl list sinks | grep Latency
        Latency: 9312 usec, configured 10000 usec

---

• With load-module module-udev-detect (fixed_latency_range disabled by default) and after playing some music / maps for about 10 minutes

# Rhythmbox
$ pactl list sinks | grep Latency
        Latency: 71797 usec, configured 76000 usec

# Firefox - Youtube
$ pactl list sinks | grep Latency
        Latency: 50990 usec, configured 56000 usec

# osu!
$ pactl list sinks | grep Latency
        Latency: 85991 usec, configured 86000 usec
$ pactl list sinks | grep Latency
        Latency: 75127 usec, configured 76000 usec

---

• Changing osu-framework source code

# With PlaybackBufferLength = 500
#      Bass.UpdatePeriod = 5
$ pactl list sinks | grep Latency # After about 10 min
        Latency: 75267 usec, configured 76000 usec

---

# With PlaybackBufferLength = 1000
#      Bass.UpdatePeriod = 5
$ pactl list sinks | grep Latency # After about 10 min
        Latency: 75645 usec, configured 76000 usec

---

# With PlaybackBufferLength = 100
#      Bass.UpdatePeriod = 50
$ pactl list sinks | grep Latency # After about 10 min
        Latency: 58929 usec, configured 66000 usec
$ pactl list sinks | grep Latency # After about 40 min
        Latency: 70274 usec, configured 76000 usec

---

I'm pretty sure the local framework setting was correct.

If it interests, these are the commands and its outputs when I was building osu!.

root@db2a8ce2993a:/code/osu# CSPROJ="osu.Game/osu.Game.csproj"
root@db2a8ce2993a:/code/osu# SLN="osu.sln"
root@db2a8ce2993a:/code/osu# dotnet remove $CSPROJ package ppy.osu.Framework;
info : Removing PackageReference for package 'ppy.osu.Framework' from project 'osu.Game/osu.Game.csproj'.

root@db2a8ce2993a:/code/osu# dotnet sln $SLN add ../osu-framework/osu.Framework/osu.Framework.csproj ../osu-framework/osu.Framework.NativeLibs/osu.Framework.NativeLibs.csproj;
Project `../osu-framework/osu.Framework/osu.Framework.csproj` added to the solution.
Project `../osu-framework/osu.Framework.NativeLibs/osu.Framework.NativeLibs.csproj` added to the solution.

root@db2a8ce2993a:/code/osu# dotnet add $CSPROJ reference ../osu-framework/osu.Framework/osu.Framework.csproj
Reference `..\..\osu-framework\osu.Framework\osu.Framework.csproj` added to the project.

root@db2a8ce2993a:/code/osu# dotnet publish -r linux-x64 osu.Desktop --self-contained --configuration Release
Microsoft (R) Build Engine version 16.0.450+ga8dc7f1d34 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 408.17 ms for /code/osu-framework/osu.Framework.NativeLibs/osu.Framework.NativeLibs.csproj.
  Restore completed in 33.89 sec for /code/osu-framework/osu.Framework/osu.Framework.csproj.
  Restore completed in 57.43 sec for /code/osu/osu.Game.Rulesets.Catch/osu.Game.Rulesets.Catch.csproj.
  Restore completed in 57.07 sec for /code/osu/osu.Game.Rulesets.Mania/osu.Game.Rulesets.Mania.csproj.
  Restore completed in 23.64 sec for /code/osu/osu.Game.Rulesets.Osu/osu.Game.Rulesets.Osu.csproj.
  Restore completed in 248.93 ms for /code/osu/osu.Game.Rulesets.Taiko/osu.Game.Rulesets.Taiko.csproj.
  Restore completed in 246.9 ms for /code/osu/osu.Game/osu.Game.csproj.
  Restore completed in 1.19 min for /code/osu/osu.Desktop/osu.Desktop.csproj.
  osu.Framework.NativeLibs -> /code/osu-framework/osu.Framework.NativeLibs/bin/Release/netstandard2.0/osu.Framework.NativeLibs.dll
/root/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5): warning : Unable to locate repository containing directory '/code/osu-framework/osu.Framework'. [/code/osu-framework/osu.Framework/osu.Framework.csproj]
/root/.nuget/packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/Microsoft.SourceLink.Common.targets(53,5): warning : Source control information is not available - the generated source link is empty. [/code/osu-framework/osu.Framework/osu.Framework.csproj]
Graphics/Sprites/FontAwesome.cs(4340,37): warning CS0108: 'FontAwesome.Solid.Equals' hides inherited member 'object.Equals(object)'. Use the new keyword if hiding was intended. [/code/osu-framework/osu.Framework/osu.Framework.csproj]
  osu.Framework -> /code/osu-framework/osu.Framework/bin/Release/netstandard2.0/osu.Framework.dll
  osu.Game -> /code/osu/osu.Game/bin/Release/netstandard2.0/osu.Game.dll
  osu.Game.Rulesets.Osu -> /code/osu/osu.Game.Rulesets.Osu/bin/Release/netstandard2.0/osu.Game.Rulesets.Osu.dll
  osu.Game.Rulesets.Mania -> /code/osu/osu.Game.Rulesets.Mania/bin/Release/netstandard2.0/osu.Game.Rulesets.Mania.dll
  osu.Game.Rulesets.Catch -> /code/osu/osu.Game.Rulesets.Catch/bin/Release/netstandard2.0/osu.Game.Rulesets.Catch.dll
  osu.Game.Rulesets.Taiko -> /code/osu/osu.Game.Rulesets.Taiko/bin/Release/netstandard2.0/osu.Game.Rulesets.Taiko.dll
  osu.Desktop -> /code/osu/osu.Desktop/bin/Release/netcoreapp2.2/linux-x64/osu!.dll
  osu.Desktop -> /code/osu/osu.Desktop/bin/Release/netcoreapp2.2/linux-x64/publish/

Not sure if it is relevant, but I used this docker image to compile osu!.

[YaLTeR]

Hey, I guess this is the most relevant issue.

Over the past couple of days I investigated Linux audio sample latency in Quaver where we also use ManagedBass. I was able to achieve basically perfect hitsound latency on the default PulseAudio config on Arch Linux. The necessary changes were pointed out to me on the BASS forum:

• Bass.Configure(Configuration.DevNonStop, true); fixes the sample playback latency being inconsistent (small when nothing else is playing and large otherwise);
• make DevicePeriod and DeviceBufferLength configurable by the user: by setting them to lower values than the default ones I was able to reduce the audio latency from significant to basically zero, but it can introduce crackling artifacts which probably depend on the sound card and whatnot.

All of this must be set before calling Bass.Init().

[ArniDagur]

Would you mind sharing the patches you made so that I can try them out?

[smoogipoo]

@YaLTeR interesting to know, that's revealed that lazer is lacking a few of these settings which stable already had. Before going down the path of user setting, we're considering the possibility of updating BASS ourselves, since we already run a separate audio thread.

[YaLTeR]

@ArniDagur find where osu-framework calls Bass.Init() and _before that_ put:

Bass.Configure(Configuration.DevNonStop, true);
Bass.Configure(Configuration.DevicePeriod, 2);
Bass.Configure(Configuration.DeviceBufferLength, 4);

these values work for me in Quaver (actually lowest are 1 and 2 which also do work for me), but for you they might crackle as I said. You can try increasing them. As per BASS docs, the buffer length needs to be a multiple of, and at least double of the period, but BASS will round it up appropriately.

[Yutsuten]

I've discovered some interesting things here.

Currently I have dual boot to _Arch Linux_ and _Debian 9_. First I tried the settings mentioned by @YaLTeR in my Arch Linux.

Arch Linux
With DevNonStop as true, DevicePeriod as 2 and DeviceBufferLength as 4, my initial latency was around 2ms, which is great. But after playing a map, it was raised to 9ms by PulseAudio. Still very nice.

Then I tried without the DevicePeriod and DeviceBufferLength setting. My initial latency was 10ms, and it kept this value even after ~30min playing, so I guess it won't change.

Until here everything was nice. Then I copied the binaries to my Debian and tried there.

Debian 9
My surprise: my latency was still increasing as crazy. The results were the very same as the ones I posted previously. The latency raised to 76ms after playing 3 maps, with both configurations (with and without DevicePeriod and DeviceBufferLength)

---

This intrigued me. I started to suspect that the changed configurations weren't improving anything at all. So I catched the binary with all the default configurations (no DevNonStop, DevicePeriod and DeviceBufferLength setting), the very one that gave me bad results a month ago in Debian, and copied to Arch Linux.

After playing for ~40 min, I checked my latency. It was 10ms. It was running great.

---

My guess is that PulseAudio at Debian 9 has a bug that Arch Linux don't. Debian aims for stability, so it uses old packages. Arch Linux uses cutting edge packages. Was the latency bug in PulseAudio from the very beginning? I thought that I would find some answers with this tests, but looks like I only found more questions...

[YaLTeR]

it was raised to 9ms by PulseAudio

I actually did observe raising latency over play time on my machines. Mainly on my laptop running Fedora in osu! under wine, the latency is crazy (-60ms universal offset), but it almost doubles over a session. In Quaver the latency starts out small and increases a little over a session. On my Arch desktop that doesn't seem to happen, at least not to an audible extent.

Is there some way you use to see the actual latency values, or do you check it manually by ear? Are you sure it's PulseAudio and not some other component? Do you know of any way to prevent PulseAudio from raising the latency?

[Yutsuten]

Is there some way you use to see the actual latency values

pactl list sinks | grep Latency

You can try without the grep to see the full output.
http://manpages.ubuntu.com/manpages/xenial/man1/pactl.1.html

---

Do you know of any way to prevent PulseAudio from raising the latency?

Yes, I posted it already.
https://github.com/ppy/osu/issues/3800#issuecomment-487592593

[YaLTeR]

Thanks a lot, I will try this out.

My guess is that PulseAudio at Debian 9 has a bug that Arch Linux don't.

Is your setup otherwise identical between the two systems? I noticed that CPU load can cause more frequent audio glitches, so maybe it's that on Debian you have something loading up the system, causing more underruns and therefore the latency being raised by PA.

[Yutsuten]

Yes, they are identical. I always avoid to install things that run in the background.
And on Debian I was running only osu! and the terminal when I was doing the tests.

[gogoprog]

...
Hope it helps!

Thanks it was useful to read.
In my case I had to use

default-fragments = 2 ; minimum seems to be 2
default-fragment-size-msec = 15

in the daemon.conf to reduce the latency.

Went from 100ms to 30ms which is better in games.

[YourSandwich]

I used to have around up to 200ms audio delay with pulse on manjaro, changing the pulse config like this fixed it for me: https://ludwig.im/en/projects/steam-pulseaudio-sound-latency-lagging-problem-noise#optimize-pulseaudio-settings-for-steam-games

this fixed it for me to!!!
Spec:
Optimsu laptop with GTX 1050 on manjaro kde

[flopglop]

If PulseEffects is open for some reason the audio latency suddently dissapears. (Atleast on manjaro kde)
Edit:
You can see this in this video: https://streamable.com/427crq

[YourSandwich]

If PulseEffects is open for some reason the audio latency suddently dissapears. (Atleast on manjaro kde)
Edit:
You can see this in this video: https://streamable.com/427crq

I have the same results, PulseEffects is applaying a custom /etc/pulseaudio/deamon.conf config which is the reason for low latency but i cant figure it out how to modify it by my self.

I heard that manjaro is using alsa drivers and converting them to pulseaudio, im not sure.

These latency is just on my amd laptop with ryten 3500U, on my PC with an RTX2060 and intel cpu there is a much smaller latency, my laptop us getting an update rate of 700 and 1ms audio ingame.

It looks like im getting wrong timings in game osu standart when my system audio latency is high. It seems like these two factors are corelating.

[leandiez]

Hello! Same issue here. I'm playing on Manjaro 20 KDE with Lutris.

After see this thread, I found in System Options a checkbox for Reduce PulseAudio latency. Activating that solves the problem of latency with hitsounds.

Would be nice to know what this option do for implementing a solution in the osu! code, but i think the problem its more related with certains Linux distributions using PulseAudio.

Please let me know if the image its no posted rightly, im not a very frequent colaborator on GitHub n.n"

[YourSandwich]

Hello! Same issue here. I'm playing on Manjaro 20 KDE with Lutris.

After see this thread, I found in System Options a checkbox for Reduce PulseAudio latency. Activating that solves the problem of latency with hitsounds.

Would be nice to know what this option do for implementing a solution in the osu! code, but i think the problem its more related with certains Linux distributions using PulseAudio.

Please let me know if the image its no posted rightly, im not a very frequent colaborator on GitHub n.n"

Yes mate thanks for the solution, this is working acctualy but i knew about it. The prblem is with Osu Lazer not with Wine Osu ;)

Yes the problem is for sure on pulseaudio config side not osu itself. But somehow Osu Lazer is dependent on that latency and you get latency while clicking even when the audio is of.

[flopglop]

Hello! Same issue here. I'm playing on Manjaro 20 KDE with Lutris.

After see this thread, I found in System Options a checkbox for Reduce PulseAudio latency. Activating that solves the problem of latency with hitsounds.

Would be nice to know what this option do for implementing a solution in the osu! code, but i think the problem its more related with certains Linux distributions using PulseAudio.

Please let me know if the image its no posted rightly, im not a very frequent colaborator on GitHub n.n"

At least for me the Reduce PulseAudio latency toggle dosen't make the latency dissapear completely, but at least it reduces the latency enough for the latency offset slider in the setting to be useful. (I have it at 188ms and I can't see any latency anymore)

In terms of implementing this in osu, lutris is open source (https://github.com/lutris), so making osu show a textbox saying something like "This system seems to use pulseaudio. Do you want to enable a fix for the latency?" and then doing the same thing as lutris does could work decently.

@YourSandwich osu lazer shows up as regular osu on lutris even if you use the linux native version.

[YourSandwich]

Hello! Same issue here. I'm playing on Manjaro 20 KDE with Lutris.
After see this thread, I found in System Options a checkbox for Reduce PulseAudio latency. Activating that solves the problem of latency with hitsounds.
Would be nice to know what this option do for implementing a solution in the osu! code, but i think the problem its more related with certains Linux distributions using PulseAudio.

Please let me know if the image its no posted rightly, im not a very frequent colaborator on GitHub n.n"

At least for me the Reduce PulseAudio latency toggle dosen't make the latency dissapear completely, but at least it reduces the latency enough for the latency offset slider in the setting to be useful. (I have it at 188ms and I can't see any latency anymore)

In terms of implementing this in osu, lutris is open source (https://github.com/lutris), so making osu show a textbox saying something like "This system seems to use pulseaudio. Do you want to enable a fix for the latency?" and then doing the same thing as lutris does could work decently.

@YourSandwich osu lazer shows up as regular osu on lutris even if you use the linux native version.

ow ok, i didnt know, iam compileing it by my self, so maybe i try to import it to lutris and use it like on regular osu :D

[smoogipoo]

Last I brought this up the consensus was to not apply any such changes to osu! and let system maintainers decide the best settings for their system.
I'm tending to agree a bit these days since there are many different hardware combinations and the settings there might not work for all and would be even harder for users to fix. Then there's different audio subsystems to consider as well, different versions, etc - the list goes on.

There are better changes you can make (see: http://juho.tykkala.fi/Pulseaudio-and-latency), but with Linux you're expected to have the system under your own control. The PA defaults are there as a general solution and are not optimised for your hardware.

Also fwiw all that Lutris is doing is setting the environment variable PULSE_LATENCY_MSEC=60 for osu!.

[flopglop]

Fair enough, however there should be something that at least tells you where you can get help, since people who just switched to linux might not know how to solve it.