Hitsounds and metronome delayed in the chart editor

[OrbyyOrbinaut]

Please check for duplicates or similar issues, as well performing simple troubleshooting steps (such as clearing cookies, clearing AppData, trying another browser) before submitting an issue.

If you are playing the game in a browser, what site are you playing it from?

• Newgrounds
• Itch.io? Specify below
• • Windows
• • Mac
• • Linux

If you are playing the game in a browser, what browser are you using?

• Google Chrome (or chomium based like Brave, vivaldi, MS Edge)
• Firefox
• Safari

What version of the game are you using? Look in the bottom left corner of the main menu. (ex: 0.2.7, 0.2.1, shit like that)

0.3.2

Have you identified any steps to reproduce the bug? If so, please describe them below in as much detail as possible. Use images if possible.

Just seems like a general bug with the chart editor.

Please describe your issue. Provide extensive detail and images if possible.

The hitsounds and metronome sound very delayed in the chart editor, see videos below:

Hitsounds:

2024-05-08_20-45-41.mp4

Metronome:

2024-05-08_20-47-42.mp4

If you're game is FROZEN and you're playing a web version, press F12 to open up browser dev window, and go to console, and copy-paste whatever red error you're getting

[EliteMasterEric]

This is a bug I've tried to figure out on and off for a while and haven't been able to resolve.

Tagging this as help wanted to indicate this is a great issue for the community to tackle.

[ACrazyTown]

This is a bug I've tried to figure out on and off for a while and haven't been able to resolve.

Tagging this as help wanted to indicate this is a great issue for the community to tackle.

It seems to be an issue with the OpenAL Soft time change on Funkin's Lime fork. I tried the fork on a different non-FNF related project and it seemed to suffer the same issue

[ACrazyTown]

I'm not sure if this is entirely correct but I believe the issue is with how the hit sounds and the metronome are handled.
They rely on the audio time which, due to the timing changes in Funkin's Lime fork, includes compensation for device latency. The audio time is approximately equal to the time as the user hears it, and there's a delay from when it was actually played internally and when the user hears it through the speakers.
The previous method for sound position Lime used got the exact sound position in the buffer aka when it was actually played.
So the Conductor currently would be calculating measures, beats and steps based on a delayed audio time and not when the sound is actually played, resulting in a delay with the hitsounds and metronome.

This could potentially be solved by having two seperate functions, one for audio time with latency compensation, and one for audio time straight from the buffer depending on the use.

Again, I might be wrong, if I am please someone correct me lol!

[ACrazyTown]

Also worth noting, the OpenAL Soft config allows customizable period sizes which would allow for higher audio precision with the old method Lime uses for calculating audio time.
The lower the period size is, the more often the audio time will update (currently it's ~20ms). The downside to this is that as the period size gets lower it will need higher CPU usage to process, which may result in performance issues on weaker hardware.

[Lasercar]

This issue has a pending PR?

[ACrazyTown]

I have a lime PR that might help out in resolving this: openfl/lime#1896
Instead of compensating for latency directly in the audio time, there's now a seperate field to query the estimated audio source latency. With this you can get the audio position in the buffer (AudioSource.currentTime) and also the estimated time as the user hears it (AudioSource.currentTime + AudioSource.latency) depending on the use