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:

• https://github.com/ppy/osu/issues/29974
• https://github.com/ppy/osu/issues/26237
• https://github.com/ppy/osu/issues/23992
• https://github.com/ppy/osu-stable-issues/issues/306 (stable counterpart)
• https://github.com/ppy/osu/issues/32472
• https://github.com/ppy/osu/discussions/27567
• https://github.com/ppy/osu/discussions/30692
• https://github.com/ppy/osu/discussions/30552

Potential fixes:

• Candidate fix: Disabling HPET see instructions
• Remove ASUS Sonic Studio
• Reinstalling windows
• Switching to linux (lol)
• Try enabling 'experimental audio mode' / WASAPI shared mode (added in 2025.1029.1-lazer)

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. (https://github.com/ppy/osu/discussions/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

[VincentPatalinghug]

OKAY. I have been running around in circles(pun intended) on this for the last two weeks, and I think I can finally provide an update with meaningful findings. To preface, I am not so sure as to the extent my findings are applicable to other individuals' systems who are affected by this audio offset drift issue. Hopefully others that are impacted could test my findings as well!

This is a bit of a LOONG one, but here's an overview to begin with.

Overview

• On Windows systems, putting your system to "Sleep" or "Hibernate" signals your device drivers to go into a low power (but not off) state.
• Waking up the system (and in turn the drivers) from these power states evidently resulted in audio offset drift on osu after some time of playing.
• Drift can be introduced faster by all the various ways other users have reported as the cause (such as alt-tabbing, quickly pausing/unpausing songs, etc.)
• This additionally caused some audio cracks/pops every now in then, inside and outside of osu.
• Since Windows 8, Windows' default "Shutdown" method is called "Fast Startup", which basically is a "Hibernate"
• TO SET YOUR SYSTEM UP IN A STATE WHERE AUDIO OFFSET DRIFT DOESN'T* OCCUR DUE TO THIS POWER STATE ISSUE , do one of the following:
  1. When the system is on, perform a system "RESTART".
  2. From any "OFF" state, unplug your computer's power/battery completely, then power on again.
  3. DISABLED Windows' "Fast Startup", then perform a "SHUTDOWN" and boot up again.
• *Caveats to these fixes:
  • It persists until you perform one of the actions that introduces the issue (See "Replicating the Issue").
  • Some audio drivers/devices are configured by default to go into an "idle" state after some time of not receiving audio. Waking up the device from this idle state, for whatever reason, introduces audio drift issues. (See "Forcing Driver Power State to D3 After Idle Time via Registry Edit")

What I Tried

My focus the last two weeks was around narrowing down the specific system "states" (settings, drivers, software, hardware, etc.) that would result in audio offset drift to occur after some time of playing.

I tried countless things, with some things seemingly working, only to have the issue again the next day(this is an important note).

I tried things such as:

• Different audio drivers
• Different in-game settings
• Various Windows settings
• Using headphones connected to the front-panel, directly to the motherboard, through a DAC with USB and S/PDIF
• BCD settings (useplatformclock, disabledynamictick, useplatformtick, tscsyncpolicy)

After many iterations of changing settings and trying them for multiple hours (and trying to gain audio drift again when changes seemingly worked), and a ton of research, I finally narrowed down a specific system state that has reliably resulted in the audio offset drift for me: (Audio) Device power state changes.

More specifically, I believe it's when the audio driver/device changes from the D3Hot state to the D0 state (D0 = fully on state). Some reading on Windows System Power States and Device Power States

Replicating the Issue

I could be wrong here, but my reasoning for as to why it's the change from a D3Hot state to D0 is due to the ways I got to a system state where audio drift occurred:

1. Sleep(S3) to On(S0)
2. Hibernate (S4) to On(S0)
3. "Shutdown" to On(S0) With Windows "Fast Startup" Enabled (Basically S4)
4. Forcing Driver Power State to D3 After Idle Time via Registry Edit

S3/S4 to S0

These two methods are fairly simple:

1. Put the system to Sleep or Hibernate
2. Turn the system on
3. Play osu and eventually get audio offset drift issues

S4 w/ Fast Startup to S0

A shutdown method called "Fast Startup" was introduced and made the default shutdown method since Windows 8. This basically means that clicking "Shut Down" is actually doing a "hybrid" Hibernate under the hood, which potentially causes issues that would otherwise be resolved with a real Shut Down.

This does not apply to Restart, which actually does do a real shutdown. Doing a Restart is one way to set not get audio drift issues!!!

This is why some "fixes" seemed to actually work initially: the "fixes" that required a Restart was working only because of the Restart itself.

This means that to induce audio offset drift with this method:

1. "Shutdown" with Fast Startup enabled
2. Turn the system on
3. Play osu and eventually get audio offset drift issues

Forcing Driver Power State to D3 After Idle Time via Registry Edit

Vendors can create audio drivers that define idle timers, and a state to which the hardware should transition into when there is no activity with the driver within the defined idle timer. Microsoft Documentation can be found here.

The audio drift issue can be set up when your audio device goes into a D3 state and wakes up through this implementation as well.

For me, my "idle time" values were set to zero (disabled) initially, but increasing it to 5 seconds allowed me to test and confirm that this was also causing the drift issue.

I was able to see the power state of the driver under the "Power data" property in the Device Manager Details tab here:

I wont go into too much detail on how to check and edit registry values here since incorrect edits could cause issues for people.

Other Related Findings

Intel High Definition Audio Specification

I read Intel's hardware documentation a bit, and found info around "wall clocks", "link clocks", and just "clock". I didn't spend too much time here, but it does mention the clock being stopped with the device is in D3 state, but it mentions cases where the clock could be kept on while in D3 if it's needed and stopped again when no longer needed.

This ability to resume and suspend the clock while in D3 state is interesting and possibly could explain differences in audio devices?

Next Steps

• It might be worth finding others who are actively experiencing this issue and see if any of the "fixes" have any effect on their experience, as well as having others who are not experiencing this issue attempt to recreate it?
• If anyone wants me to test other things relating to these findings, or if anyone wants further explanation on anything, I'm happy to do so.
• I read up a bit on BASS docs, but not enough yet to know any possible correlation to my findings. I'm interested to know if anyone with more knowledge on BASS can think of anything that could be used to mitigate/resolve timing issues from these power state changes.

[Xacla]

I've had the offset drift issue since 2020 and I still could not find a permanent fix. Since then I've had a great variety of systems and it always occured sooner or later. It's worth mentioning that I am a mania player and have the same drift issues in almost every rhythm game if that helps to narrow some causes down. current specs: CPU: AMD Ryzen 5 3600 6-Core Processor, 3600 Mhz GPU: AMD Radeon RX 6700 XT Motherboard: MPG B550 Gaming Plus RAM: 16GB G-Skill ddr 4 Windows 11 Here is a video that demonstrates my offset drift, it feels like the hitposition is gradually moving up throughout the map: https://youtu.be/6nXKkCpH_Ms?si=xvA428AWcaO5gn_e

perhaps someone could create a discord server regarding this issue and we could try to gather more info together

[notvhale]

I started playing only Lazer at the end of 2023, did not notice the drift until around september-october '24. Did not change anything in my pc or osu setting as far as I remember, maybe some audiorouting stuff but reinstalling Windows did not fix it. In october did these screenshots to demonstrate the drift: https://imgur.com/a/epic-hM8FPfE Drift is not as huge as mentioned above- around +-15ms and goes both ways. I don't think there's drifting while playing because UR is low, but it can drift between two plays in a row. And it is not the hibernation/fast startup problem since it occurs even if computer is fully restarted and its disabled in my bios. Specs: CPU: Intel Xeon E5-2680 v4 MB: Some chinese motherboard for this cpu RAM: qiyida 16gb DDR4 some chinese ram GPU: AMD RX 470 Windows 10 22h2 19045.5608 (current)

Deleting drivers, any audio related programs, turning useplatformclock on and off, reinstalling windows(10->10) did not help. Installing Linux did help where I fully disabled global offset. On Windows i used at least -12ms before the drift and even more (up to -21ms) after the drift Also I don't know if it's only audio or visual offset too because i'm always playing HD

[peppy]

I don't believe you are describing the same issue as in this thread. Users in this thread are reporting drift that increases over time. 10-15 ms between plays sounds like a different issue altogether.

[Xacla]

I know that stable is not a priority at the moment but std seems to work fine while mania still has the offset drift. Hope that helps to narrow some causes down! I will record some more demonstration videos later. Actually I will do it for stable and lazer

[Soggy-Pancake]

I just began running into this issue today. My audio starts out fine and over time drifts and causes the notes to be super late. I haven't measured it but I would say it was probably +300ms before I couldn't take it and had to restart the game.

Specs: CPU: Ryzen 5 5600x MB: Asrock b450m pro4 (Realtek audio) GPU: RTX 3080

Windows 22H2 (19045.5608)

[peppy]

I know that stable is not a priority at the moment but std seems to work fine while mania still has the offset drift. Hope that helps to narrow some causes down! I will record some more demonstration videos later. Actually I will do it for stable and lazer

The only thing I can think of that's difference is that mania may be playing more samples over a beatmap when compared to an osu! beatmap?

[Xacla]

That could be, or I am just not a good enough osu!std player to notice the drift as much. But yeah higher mania maps have a ton of notes which makes sense why it's so noticiable there.

[Xacla]

Since the latest update the issue is resolved for me on all devices! (in stable, I have yet to check lazer)

[peppy]

we didn't change anything so maybe there was a driver update pushed for you

[fleuph]

So I thought I had beed experiencing this before but obviously not the issue, according to

I haven't measured it but I would say it was probably +300ms before I couldn't take it and had to restart the game.

Specs: Windows 10 Pro (Build 19045) Gigabyte B550M Ryzen 5 5600X 32GB 3200 MHz RTX 3060 Behringer U-PHORIA UMC 202HD

This must be a skill issue but what I experience is that throughout a session my local offset on the same map will drift over time. For example, I'll start off not needing offset then come back to the map 45 minutes later and all of a sudden I'm hitting 15ms early. But I've never experienced offset drift into the hundreds of milliseconds.

Looking at VincentPatalinghug's testing, I think the reason I do not experience this might be because I rarely turn off my computer or put it in sleep mode. I generally leave it on at all times and then restart it in the morning (I just turn my monitors off and go to bed).

Alternatively, some of the programs I run to address memory leaks and manage CPU use could be helping out. I have Intelligent Standby List Clear and ParkControl running at all times. I originally installed these to manage lag spikes that got more frequent as I played longer on both stable and lazer, and haven't had that issue since. IDK if these would be related in any way but wanted to include them.

[Xacla]

Update: 2 days ago the problem occured again in every rhythm game, so it seems to be driver related.

[szmarczak]

I don't think it's a driver issue. I have a Focusrite Scarlett 2i2 (3rd gen) and official driver installed. After I alt-tab, hit sounds are at least a few ms delayed (maybe even 10ms, I haven't measured it). This is highly noticeable when playing streams. After I change the audio device & set it back, the problem is fixed.

[bdach]

As an update, there have been some reports that the experimental audio mode (WASAPI shared) which has been added to the latest lazer release alleviates issues with offset drift, so anyone experiencing these is encouraged to try the option and see if it improves the situation.

[Rick-Bossen]

I haven't noticed any offset drift in my last few sessions with the new wasapi changes, my offset remained pretty much stable at around -35ms :)