Based on feedback I've heard more than once ([most
recently](https://github.com/ppy/osu/discussions/36933)), there's too
much overlap compared to stable. And it can sound a bit "jumbled" as a
result, especially when transitioning between two songs with loud and
"complex" audio.
This also fixes noticeable audio glitching that some users may have been
experiencing when switching tracks.
---
Unless there's any very loud objections, I'd ask that review is on the
code not the audible change. This is the kind of change that I tweak to
my personal spec and then push out to hear the general reaction.
### b8d0dfe2ed Better default preview time
based on global fade
This is an oversight. The preview point wasn't being offset to account
for the fade in. This is something we do when generating web-side
previews, which allows for the actual preview point to be audible,
rather than mid-fade.
### 8de323b68c Adjust fade in and fade out
during track transitions to reduce overlap
Yes, I'm aware that the delay is not accounted for in the constant. This
is intentional because it sounds better. I want this to be an internal
adjustment which is not to be considered by any external usages of those
constants. Just sounds better.
### aab01b0fe5 Remove weird/dated schedule
usage
This causes audible artifacts in playback. The track is not set to zero
volume early enough. Original change was made in [this ancient
PR](https://github.com/ppy/osu/pull/9792) (see
[commit](https://github.com/ppy/osu/commit/688e4479506645bdacee7cdc7ae9ee9deaa5f1b4)).
The original failure does not occur. Tests still pass. I'd argue that if
we encounter this again, it's an issue at the call site, not this code.
This is a drive-by fix, as I noticed this glitching while working on the
main issue here. Arguably should be it's own PR 🤷 .
By falling back to the default of 40% of track duration in such cases.
Also added a safety for the restart point exceeding acceptable bounds in
case of a non-zero offset.
Closes https://github.com/ppy/osu/issues/33308.
This is an effort to improve general performance at song select. At
least on the metal renderer, I can notice very high draw frame overheads
related to texture uploads.
By reducing the size of the texture uploads to roughly match what is
actually being displayed on screen (using a relatively inexpensive crop
operation), we can bastly reduce stuttering both during initial load and
carousel scroll.
You might ask if it's safe to disable mipmapping, but I've tested with
lower resolutions and bilinear filtering seems to handle just fine.
Bilinear without mipmaps only falls apart when you scale below 50% and
we're not going too far past that at minimum game scale, if at all.
Will still keep the override in `ClockBackedTestWorkingBeatmap` because
it still relies on a local track store and will fail the moment it uses
a non-virtual track.
A lot of tests are using test resources that populate the length field,
but do not populate hitobjects. The general expectation is that
components should be using the cached length in cases where hitobjects
are not relevant, but `GetVirtualTrack` was doing its own local
calculation.
This could cause tests to fail due to `MusicController` changing track
in the background.
After the recent changes introducing cancellation support to
`WorkingBeatmap`, it turned out that if the cancellation support was
used, `GetPlayableBeatmap()` would raise timeout exceptions rather than
the expected `OperationCanceledException`.
To that end, split off a separate overload for the typical usage, that
catches `OperationCanceledException` and converts them to beatmap load
timeout exceptions, and use normal `OperationCanceledException`s in the
overload that requires a cancellation token to work.