Audio offset drift on some hardware configurations

[peppy]

This has been reported countless times but the history of these reports and potential solutions is a mess, so I'm opening a new tracking issue with everything we know.

Overview of issue:

Users are reporting offset drift that worsens over hours of gameplay. The drift is reset by restarting the game, or changing audio output devices.

Relevant issues:

• Beatmap desync / fluctuating offset after changes to filesystem (e.g. downloading/deleting beatmaps) #29974
• lag between visual/sound until restart #26237
• Notes and music desynchronized after playing for a while #23992
• Circles increasingly off-beat osu-stable-issues#306 (stable counterpart)
• Game randomly changes audio offset #27567
• Problem: Offset of the map shifting. #30692
• Notes and music desynchronized after playing for a while #30552

Potential fixes:

• Candidate fix: Disabling HPET see instructions
• Remove ASUS Sonic Studio
• Reinstalling windows
• Switching to linux (lol)

Next steps:

Gather further feedback and report back to BASS, as this looks to be a BASS issue.

[peppy]

For anyone still encountering this issue

From an admin command prompt:

bcdedit /set useplatformclock Yes

Importantly, you should undo this once you're finished testing. It could have a permanent adverse effect on system performance:

bcdedit /deletevalue useplatformclock

Further reading:
[1] https://en.wikipedia.org/wiki/High_Precision_Event_Timer
[2] https://en.wikipedia.org/wiki/Time_Stamp_Counter
[3] https://sites.google.com/view/melodystweaks/misconceptions-about-timers-hpet-tsc-pmt#h.qa7l8zto31mq
[4] https://sites.google.com/view/melodystweaks/misconceptions-about-timers-hpet-tsc-pmt#h.p2s50iipdstx

[stanriders]

useplatformclock seems to help

AMD Ryzen 5700X3D on MSI B450M-A PRO MAX (MS-7C52)
Windows 10 Version 10.0.19045 Build 19045
Yamaha AG-03 DAC, onboard audio disabled in BIOS

[Zyfarok]

@peppy Correct me if I'm wrong, but to my limited understanding (from the little search I did on the topic), it seems the default value of useplatformclock can be different from one system to another (and some might even have the value undefined, which is some kind of "auto" mode ?).
So if that's indeed the case, the "safe" process should be to first run bcdedit /enum to check the initial value before doing anything, and the undo step would depend on that. (i.e. bcdedit /delete useplatformclock if the value was not present)

[peppy]

@peppy Correct me if I'm wrong, but to my limited understanding (from the little search I did on the topic), it seems the default value of useplatformclock can be different from one system to another (and some might even have the value undefined, which is some kind of "auto" mode ?). So if that's indeed the case, the "safe" process should be to first run bcdedit /enum to check the initial value before doing anything, and the undo step would depend on that. (i.e. bcdedit /delete useplatformclock if the value was not present)

Thanks, I've updated the documentation above.

[VincentPatalinghug]

I've had this problem for a few years now and decided to deep dive into it the past week. useplatformclock unfortunately made my computer beg for mercy after enabling and restarting. Took me 5 minutes to open command prompt and disable it -- I ended up not testing Osu because of this.

I was able to fix it a different way today though: Using Realtek Audio drivers instead of Windows' High Definition Audio Device drivers. (#30552) mentioned latency issues with the Realtek drivers, but I was able to make the latency low again by ensuring any audio enhancements were disabled.

I tested reverting back to using High Definition Audio Device drivers, and I was able to replicate the audio timing drift issue again. Re-installing Realtek Audio drivers resolved it again.

I will continue testing different things on my end, looking into osu-framework, and looking into BASS in case there is a more specific reason that might allow a fix/option to be implemented within osu to limit the need for users to make changes on their end.

Let me know if you'd like me to test anything else specific on my system @peppy .

My specs:

• Intel i9-9900K
• RTX 2080 Ti
• MPG Z390 GAMING PRO CARBON AC (MS-7B17)
• Windows 11 Home 10.0.26100 Build 26100

Side note: I was able to quickly replicate the audio timing drift issue by spamming Pause and Resume over and over during a song intro, or a song break. You can make it worse and worse by restarting and doing it over and over again (up to the InterpolatingFramedClock::AllowableErrorMilliseconds value).

[peppy]

Thanks for your testing.

useplatformclock unfortunately made my computer beg for mercy after enabling and restarting

This sounds really weird. It shouldn't be doing anything that egregious. Could you test another time to confirm it was actually the issue, because it sounds like something else may have been at play..

Side note: I was able to quickly replicate the audio timing drift issue by spamming Pause and Resume over and over during a song intro, or a song break. You can make it worse and worse by restarting and doing it over and over again (up to the InterpolatingFramedClock::AllowableErrorMilliseconds value).

Can you elaborate on this? Are you saying the maximum audio drift you can get is 32 ms? Once you get this drift, does it "stick" when starting playing on a different beatmap, or does it reset?

[VincentPatalinghug]

This sounds really weird. It shouldn't be doing anything that egregious. Could you test another time to confirm it was actually the issue, because it sounds like something else may have been at play..

Just tried again and it was the same case:
https://streamable.com/quj7ff -- video displaying mouse issues

Screenshot took 5 minutes, so I took a picture of this before I restarted

I did dig into this a little bit last night and saw something about an HPET setting in the BIOS but I couldn't find it for mine. I'm wondering if HPET needs to be supported and enabled in the BIOS for the useplatformclock setting to work? I will look more into this.

Side note: I was able to quickly replicate the audio timing drift issue by spamming Pause and Resume over and over during a song intro, or a song break. You can make it worse and worse by restarting and doing it over and over again (up to the InterpolatingFramedClock::AllowableErrorMilliseconds value).

Can you elaborate on this? Are you saying the maximum audio drift you can get is 32 ms? Once you get this drift, does it "stick" when starting playing on a different beatmap, or does it reset?

• Yes, the maximum audio drift I was able to get was ~32ms. I continued spamming pause/unpause, then adjusting the song offset to make it "normal" again, and I couldn't make it go past ~ -32ms (making the hit objects appear 32ms later to compensate)
• Yes it "sticks" when playing on a different beatmap for osu!lazer. I didn't do too much testing with stable -- it seems like pausing/unpausing or changing beatmaps in stable would reset it.

[peppy]

Are you able to build the game and test locally yourself? If so, I'd ask that you test with different values for the AllowableErrorMilliseconds (specifically, trying extreme values of 0 and 200) to see how things change.

Here's a diff to allow changing that setting without a local framework checkout:

diff --git a/osu.Game/Beatmaps/FramedBeatmapClock.cs b/osu.Game/Beatmaps/FramedBeatmapClock.cs
index af7be235fc..168b360548 100644
--- a/osu.Game/Beatmaps/FramedBeatmapClock.cs
+++ b/osu.Game/Beatmaps/FramedBeatmapClock.cs
@@ -59,7 +59,7 @@ public FramedBeatmapClock(bool applyOffsets, bool requireDecoupling, IClock? sou
 
             // An interpolating clock is used to ensure precise time values even when the host audio subsystem is not reporting
             // high precision times (on windows there's generally only 5-10ms reporting intervals, as an example).
-            interpolatedTrack = new InterpolatingFramedClock(decoupledTrack);
+            interpolatedTrack = new CustomInterpolatingFramedClock(decoupledTrack);
 
             if (applyOffsets)
             {
@@ -214,5 +214,15 @@ string output(IClock? clock)
                 return $"current: {clock.CurrentTime:N2} running: {clock.IsRunning} rate: {clock.Rate}";
             }
         }
+
+        public class CustomInterpolatingFramedClock : InterpolatingFramedClock
+        {
+            public override double AllowableErrorMilliseconds => 0;
+
+            public CustomInterpolatingFramedClock(DecouplingFramedClock decouplingFramedClock)
+                : base(decouplingFramedClock)
+            {
+            }
+        }
     }
 }

[Rick-Bossen]

I've yet to test the useplatformclock fix, will test it later today, but for me at least I have noticed that this issue mostly arises when i alt-tab out of the game. It is very inconsistent though, sometimes nothing happens and other times i get a pretty consistent offset resulting in me hitting ~10ms late.
What I've done up until now as a quick fix is to quickly switch my audio device in game, even changing it from default to the actual device gets the job done here.

My specs:

• Ryzen 7 5800X3D on ASRock B550M PG Riptide
• RTX 4080
• Windows 11 Pro 10.0.26100 Build 26100
• JDS Labs Atom DAC

[VincentPatalinghug]

Are you able to build the game and test locally yourself? If so, I'd ask that you test with different values for the AllowableErrorMilliseconds (specifically, trying extreme values of 0 and 200) to see how things change.

OK this is all so weird lol. I am able to build and test locally. I tried to replicate the issue again last night before running these tests, but failed to get any drift with (what I thought was) reinstalled High Definition drivers...

---

Testing Again on 2025.118.3-lazer

Drift With Evident Interpolation

I did a system restore before going to bed last night to a point before I messed with drivers.
Today I was able to replicate it again, BUT the interpolation logic seemed to reset the drift properly.
It did still "stick" to other songs, up until what I assume the AllowableErrorMilliseconds number is hit. Here's a video example:
https://drive.google.com/file/d/1C2P_xgj6vNzdL9mDvMOSk2SewfgsF5e6/view?usp=sharing

• At 0:03, you can see the drift occur.
• At 1:20, I restart and apply -20ms offset, and it works well.
• At 2:10, I switch songs to see if it sticks before interpolation kicks in, and it does stick.
• At 2:45, you can see the interpolation fix the drift.

170ms Drift

BUT I kept osu!lazer minimized while saving replays and cutting that first video, and ended up getting a 170ms drift.
https://drive.google.com/file/d/1JRkVL12t24uKGj4TnlaQOlK16RaiXhjF/view?usp=sharing

• The video is really just me trying to estimate the drift using offset lol. I ended up needing to use the universal offset since song offset is limited to +/- 50ms.

290ms Drift -- Sticking After Song Change

Here's 290ms of drift after keeping it minimized a few more minutes.
https://drive.google.com/file/d/1yXP4FvATwssQAKpgYV0b8wdG0JzYSaNn/view?usp=sharing

• At 1:09, I try a different song to check if the drift stuck, and it did.

I am assuming the ~33ms drift I was experiencing last time was similar to this, but it coincidentally just happened to be the AllowableErrorMilliseconds value.

My Thoughts/Next Steps

• I am leaning towards driver issues and/or system timing issues.
• I was going to test other bcdedit settings, specifically useplatformtick and disabledynamictick. Probably not useplatformclock Yes since that evidently did not work well for my system.
• I did try useplatformtick Yes yesterday with success, but I would like to test in an extended osu session.

---

Other Details

`bcdedit /enums`

System Restore details. The deleted and restored drivers might be worth digging into?

High Definition Audio Device driver details after System Restore

osu!lazer Audio Settings after testing

[peppy]

Great to hear it's not related to AllowableErrorMilliseconds, thanks for the extended testing.

[FrostiDrinks]

The drift doesn't seem to take place very quickly on my machine (e.g. leaving the game open overnight) so it's hard to test properly but I'm fairly certain it only happens on multithreaded mode.

• i7 9700k
• RTX 3070
• Windows 11 Pro Build 22631.4830
• Realtek (R) Audio (Internal High Definition Audio Bus) Version 10.0.22621.2506