Timing: Bugged audio drivers / hardware can cause gameplay to run too slowly

[joshuk]

Type

Game behaviour

Bug description

Day to day I currently use an external bluetooth speaker (a Sony SRS-XB01, to be specific) while doing general browsing and computer use, including watching replays on osu!

While changing my audio output device on stable, I noticed a device called 'Headset Earphone (SRS-XB01 Hands-Free AG Audio)':

Note that the screenshot from lazer, however the same audio device is also available on stable.

When switching to this audio device, all audio in the game noticably slows down (to around 50% speed I reckon). When starting a map, the gameplay also slows down accordingly. Stable seems to detect this, giving this error when submitting a score:

However, when doing this same thing in lazer, the error isn't present and the score submits. As an example, see my score on Silvia - Vertex Delta [GAMMA]. This score is 'cheated' in this way, which allowed me to play much faster than I am actually able to.

Happy to provide any further information/recordings if needed. Thanks.

Screenshots or videos

No response

Version

2023.403.1

Logs

runtime.log
updater.log
database.log
input.log
network.log
performance.log

[peppy]

I have no idea what "timewarp" means but the fact you do is likely incriminating. Could you please update the issue description to make it less obvious that you are a cheater and know the cheater terminology.

[joshuk]

I don't think that knowing the name of an extremely widespread cheating technique that's been used by several top players in the past automatically means that I'm a cheater, but appreciate the baseless accusation. Really encourages people to help point out potential integrity issues with your game.

Either way, I've updated the title to try and explain it a bit better. Feel free to ask again if you still don't understand 🙂

[peppy]

As for how we should handle this (whether it should be strictly moved to the anticheat module or also implemented in the game in a way that the user can be made aware that their hardware is borked), will require further discussion.

[joshuk]

My two cents: I feel like stable's implementation works fine here, where it shows an error message and prevents score submission.

Since this is only triggered by the user changing their audio device I could certainly see it being done innocently by someone who's maybe unsure on what they're doing. Don't think it necessarily indicates cheating.

[peppy]

That's not what I was implying. It just depends where we place the duty of checking this kind of thing in the game structure.

[ttl41]

I accidentally found another way to replicate (on Debian Linux with Pipewire, but distro-agnostic without a doubt), while messing with my settings for latency:

1. launch osu!
2. set the clock quantum to a very high value, such as with the command pw-metadata -n settings 0 clock.force-quantum 4096
3. the game slows down while allowing scores to be submitted

[rszyma]

My DAC sometimes encounters a bug where it's running at 48khz but when a program on my pc (linux) wants to run audio @ 44.1khz and it results in the sped up audio. I got this a few times in osu too, so it's kind of opposite than what this issues is about, but either way, I don't think it should be even possible to for osu gameplay to run faster/slower because mismatch in sample rate.

BTW, the I kinda liked the fact that the the other sounds like hitsounds or even menu sounds were also sped up when this bug happened, it adds to the experience :D. So maybe consider adding a toggle in settings "speed up all sounds when DT is enabled"?

[YourSandwich]

I accidentally found another way to replicate (on Debian Linux with Pipewire, but distro-agnostic without a doubt), while messing with my settings for latency:

1. launch osu!
2. set the clock quantum to a very high value, such as with the command pw-metadata -n settings 0 clock.force-quantum 4096
3. the game slows down while allowing scores to be submitted

I can confirm this. It also happens randomly since Pipewire dynamically sets the quantum clock, which can result in slowed down and distorted audio in some cases. Changing the outputs can fix this issue.

EDIT: I also encounter the same bug as @rszyma, but without a DAC. I believe the dynamic adjustment part is causing the problem. It might be possible to disable this behavior using the Pipewire API and setting a priority.