Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust audio_frame_ticks #5266

Merged
merged 4 commits into from Jun 11, 2020
Merged

Conversation

xperia64
Copy link
Contributor

@xperia64 xperia64 commented Apr 22, 2020

This pull request was created to partially address #4562

I am not confident this is the correct solution, but it just happens to fix this issue on the HLE backend from what I can tell. In some ways this PR serves as an information dump regarding the behavior I've observed.

In Project Mirai 2, on the HLE backend, the music track of a given song runs faster than the rest of the gameplay by a significant amount by the end of a 4 minute song, making gameplay very difficult. I found that by adjusting audio_frame_ticks, the speed of the music track relative to the rest of the game could be increased or decreased. By changing it from the hardware-measured 1310252 to the theoretical 1310740 (see commit comments), I found everything seemed to match the hardware well, with minor drift by the end of a song (~1ms or so), and the gameplay sunk up too, making things playable.

The reason I am hesitant to believe this is the correct answer is that it only fixes the Project Mirai series, and only on HLE. Project Mirai's HLE desync is unusual compared to the other rhythm game desync issues noted here, as in all of the other ones (#4169, #4527, #5265), gameplay gets ahead of the music track (i.e. the game is running slightly too fast, or the music track is running slightly too slow), while Project Mirai HLE has that reversed. It also differs from Project Mirai's own LLE desync, which seems to more or less match the behavior of the other rhythm games. I have not yet compared an LLE recording of Project Mirai 2 to hardware yet to determine whether the gameplay is too fast, or the song is too slow there.


This change is Reviewable

@merryhime
Copy link
Member

merryhime commented Apr 25, 2020

While my memory is hazy about this, my previous measurements were probably assuming a CPU clock speed of 268,123,480 Hz (which was an often quoted but incorrect frequency for the 3DS's CPU).

This ratio is probably better expressed as: 160 * 4096 * 2.
160 being the number of samples per frame, 4096 being the number of teaklite clock cycles per sample, and 2 being the ratio between TLII and the ARM11 CPU.

Apologies, but it's been years since I've looked at this.

@xperia64 xperia64 changed the title [WIP] Adjust audio_frame_tweaks [WIP] Adjust audio_frame_ticks Apr 26, 2020
@xperia64 xperia64 changed the title [WIP] Adjust audio_frame_ticks Adjust audio_frame_ticks Jun 11, 2020
@xperia64 xperia64 marked this pull request as ready for review Jun 11, 2020
@xperia64
Copy link
Contributor Author

xperia64 commented Jun 11, 2020

I've performed some very rough hardware testing by queuing up a very large number of samples and measuring the time it takes to process/play all of them, and can confidently say that this change is correct.

The test was performed as follows:

  1. Queue up 35000 samples in this test: https://github.com/MerryMage/3ds-audio/blob/master/AudioTest-FrameDelay/source/main.cpp
  2. Remove the printf from the loop at the bottom, and measure the time and iterations of that loop (should be just 1)
  3. Add a second loop that only calls waitForSync() and notifyDsp(), and measure the time and iterations of that loop
  4. Add the iterations and loop times; compare the results between hardware, Citra LLE, and Citra HLE

The results are as follows:

Hardware: 1388664+45871188160 ticks (171.09492100938647 seconds, 1310719.9503971655 ticks per frame), 34998 iterations
LLE (with #5402): 1353638+45871243629 ticks (171.09499725741333 seconds, 1310720.5345162582 ticks per frame), 34998 iterations
HLE (with this fix): 1330026+45873850059 ticks (1310794.3335333448 seconds, 1310719.431 ticks per frame), 35000 iterations

As can be clearly seen here, all of the results here point to 1310720 ticks per audio frame as being the correct value. I am not sure why HLE has two extra iterations (or why LLE and hardware have two fewer iterations), but the main thing that matters in this PR is that the ticks per frame are corrected. I have my suspicions regarding hle/source.cpp, but that is for another issue/PR.

@zhaowenlan1779 zhaowenlan1779 merged commit 2632b42 into citra-emu:master Jun 11, 2020
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants