From a0e8255b656969b417e517a84e4b099727ff9d89 Mon Sep 17 00:00:00 2001 From: xperia64 Date: Sun, 26 Apr 2020 03:14:54 -0400 Subject: [PATCH] Update cycles and explanation --- src/audio_core/hle/hle.cpp | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/src/audio_core/hle/hle.cpp b/src/audio_core/hle/hle.cpp index a9362de9d..23a472d04 100644 --- a/src/audio_core/hle/hle.cpp +++ b/src/audio_core/hle/hle.cpp @@ -48,18 +48,13 @@ void DspHle::serialize(Archive& ar, const unsigned int) { SERIALIZE_IMPL(DspHle) // TODO(xperia64): The value below is the "perfect" mathematical ratio -// of ARM11 cycles per audio frame. As per merry, this was calculated to be -// (ARM11 freq)*(samples per frame)/(sample rate) -// = (268,111,855.956 Hz) * (160 samples)/(32,728 Hz) -// = (1310739.946008311...) ~ 1310740 +// of ARM11 cycles per audio frame, as per merry's suggestion +// samples per frame * teaklite cycles per sample * 2 ARM11 cycles/teaklite cycle +// (160 * 4096 * 2) = (1310720) // -// This value was originally set to 1310252, which was determined by measuring it on hardware -// However, as of when this was written, Project Mirai 1/2/DX desync on HLE -// such that the music track runs ahead of the gameplay. -// When the value is set to 1310740, all three games are playable -// The audio track only drifts ~1ms over a 4+ minute song compared to hardware -// and the button presses match as well as I can determine by playing the game/recording -static constexpr u64 audio_frame_ticks = 1310740ull; ///< Units: ARM11 cycles +// As per merry, it may be useful to verify this on hardware with the more recently +// discovered "correct" ARM11 frequency of 268111856 as opposed to 268123480 +static constexpr u64 audio_frame_ticks = 160 * 4096 * 2ull; ///< Units: ARM11 cycles struct DspHle::Impl final { public: