Muted mod metronome timing offset doesn't follow audio offset or local offset

[jansenmtan]

Type

Game behaviour

Bug description

The metronome in the Muted mod doesn't change timing offset when the audio timing offset is changed. Nor does it with local offset.

Screenshots or videos

0 ms audio offset. This play is over 30 ms late.

https://user-images.githubusercontent.com/36340429/185218455-e079decc-14c7-46e3-bcfa-8461de29a010.mp4

-500 ms audio offset. This should be unplayable, but is still playable. The play is over 30 ms late.

https://user-images.githubusercontent.com/36340429/185218539-8c977397-8ba7-496b-a72d-6c46c764ae39.mp4

Map: https://osu.ppy.sh/beatmapsets/1279878#osu/2720001

Mod settings: enable metronome, always muted, mute hitsounds.

-4 ms local offset. This play is around 20 ms late.

https://user-images.githubusercontent.com/36340429/185223589-f7dcf447-c868-4bea-8749-1a2a7ae9221b.mp4

-50 ms local offset. This play is around 28 ms late.

https://user-images.githubusercontent.com/36340429/185223691-ed860a01-20a2-4c0a-ac71-fe68dd2ad17b.mp4

Version

2022.816.0-lazer

Logs

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

[peppy]

This is due to it using BeatSyncedContainer. I'm actively working on a solution to this, being roughly tracked in https://github.com/ppy/osu/issues/11400.

[peppy]

Closed via https://github.com/ppy/osu/pull/19973.

[jansenmtan]

Issue is still open as of 2022.902.1-lazer.

Varying audio offset between 0 ms, -40 ms, and -80 ms still yields average judgement offsets of ~30 ms late for each.

Varying local offset between 0 ms and 25 ms late both yield judgement offsets around 30 ms late.

[smoogipoo]

I think I can repro this. I played the keyboard latency test beatmap 4 times, in order:

1. 0ms offset, 100% volume
2. 0ms offset, metronome, 0% volume.
3. +150ms offset, metronome, 0% volume.
4. +150ms offset, 100% volume.

I was blind throughout all of these tests.

https://user-images.githubusercontent.com/1329837/188368496-7500b5c2-c48b-4a86-ac20-f0b9f118a54c.mp4

It should be pretty obvious from the judgement results alone that I believe the comment above is substantiated.

And before anyone says I started (4) off-beat, I can't fix it even if I look at the circles to make sure I'm "on beat" before closing my eyes - I picked 150ms offset specifically because it's an uneven multiple of BPM on this beatmap, so it makes sense that I shouldn't be able to recover.

[smoogipoo]

Also as a side note, I'm not sure what happened at 2:07 in the video. The metronome seems to have skipped a beat which kinda broke my brain IRL.

[peppy]

@smoogipoo can you confirm for sanity that if you adjust the universal offset while watching the same beatmap, it does adjust? can you explain what you're experiencing with that in mind so I can better understand it?

[peppy]

Watching your video looks like it's behaving correctly.

[smoogipoo]

can you confirm for sanity that if you adjust the universal offset while watching the same beatmap

I'm not sure what you mean by that. Does what adjust? The track itself adjusts, but the metronome doesn't depending on what you consider it to be "adjusting" to.

Watching your video looks like it's behaving correctly.

I don't see how you can come to this conclusion. The sounds you're hearing there aren't hitsounds, they're the track sounds. I would expect the metronome to match the track, since that's kinda the point of a metronome?

Here's another comparison, done at +150ms and 0ms respectively, with both muted mod set at 10 combo. This makes it plainly obvious they're out of sync:

https://user-images.githubusercontent.com/1329837/188373465-fc2f4b0d-5ad3-4038-a79c-12e790ca3f9a.mp4

[peppy]

I'm very hesitant to reply here because I feel like I can't explain offsets and it just causes stress for everyone involved, but here goes:

Universal offset, and its application to editor; beat synced containers; gameplay; is made to synchronise sample playback to the track. That is what all the work I did on clocks was to allow, including the metronome here.

The main purpose of offsets is to bring audio in time with samples as much as possible. For beatmaps, it's to fix mistimed beatmaps. For universal offset, it's to fix audio drivers which have incorrect clock reporting (or some degree of latency). In both those cases, the metronome and the track are offset incorrectly.

By adjusting UO, they both become correct:

https://user-images.githubusercontent.com/191335/188437707-14db7d79-aa81-4343-a682-28788fba92a9.mp4

The behaviour you (and the user mentioning things don't feel right in this PR) are wanting is basically reverting this PR for the metronome, to make it useful for input latency. But that won't work, because for the majority of cases that will cause things to sound incorrect (aka how things were before the fix was applied). In autoplay, the metronome would not be synchronised properly (because it is not applying the UO which is used everywhere else to synchronise samples and the track)

I understand what you're trying for here, but the existing offsets don't/can't work as you hope. You are trying to adjust to an input offset or otherwise, which we do not support (which is why users with very high input offsets need to turn off hitsamples).

I hope you can understand that the offsets here need to be tested using autoplay and not visual + manual input.

---

Put another way: in your video, it's showing that things ARE working because the track and samples are out-of-sync when you apply the offset.

If it wasn't to work this way, adjusting the offset on a beatmap would cause the metronome to sound out of time even though you expected to have just fixed it by adjusting the offset. Which is what this original issue brought up.