Change userBeatmapOffsetClock to a FramedOffsetClock
#27243
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Assuming that the global audio offset is set perfectly, such that any audio latency is fully accounted for, if a specific beatmap still sounds out of sync, that would no longer be a latency issue. Instead, it would indicate a misalignment between the beatmap's track and time codes, the correction for which should be a virtual-time offset, not a real-time offset.
peppy
approved these changes
Feb 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Real-time offsets are good for latency correction, since the latency does not change in size relative to the rate of playback, but there is another type of timing inaccuracy that is not caused by latency. It occurs when there is a misalignment in the beatmap itself, between its track and its timestamps.
Currently, we can use a beatmap-specific offset to correct these misalignments. The type of offset used for this is a real-time offset, the exact same type of offset that the global audio offset uses for latency correction.
The problem with this approach is that timing inaccuracies caused by misalignment are not of the same nature as those caused by latency. Unlike with latency, this type of timing inaccuracy does change in size (in real-time) relative to the rate of playback. It should therefore be corrected with a virtual-time offset.
A real-time beatmap offset will only correct the misalignment for one specific playback rate, whereas a virtual-time offset would correct the misalignment for every conceivable playback rate.
Will this break the beatmap offsets already set by users?
If the offset amount was intended to work alongside a normal playback rate of 100%, then it will work just as well as it did before. If it wasn't intended for a normal playback rate, then a new amount will need to be specified, but once a virtual-time beatmap offset works for one playback rate, it will work for every other playback rate as well, which means that fewer adjustments overall will need to be made in the long run.
Here are some examples:
Before (beatmap offset is an
OffsetCorrectionClock)before.mp4
You'll notice that at 100% playback rate, timing sounds perfectly fine, but the more it deviates from 100%, the larger the delay becomes, especially at slower speeds. There's also a slight delay at faster speeds, but it's less pronounced.
After (beatmap offset is a
FramedOffsetClock)after.mp4
After offsetting with virtual time, the delay disappears.