From 3a1601a5342f9d4fb661525356c97b34932bdac3 Mon Sep 17 00:00:00 2001
From: xperia64 <xperiancedapps@gmail.com>
Date: Tue, 21 Apr 2020 23:40:34 -0400
Subject: [PATCH 1/4] Change audio_frame_ticks with length explanation
---
src/audio_core/hle/hle.cpp | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/audio_core/hle/hle.cpp b/src/audio_core/hle/hle.cpp
index df52f461b..a9362de9d 100644
--- a/src/audio_core/hle/hle.cpp
+++ b/src/audio_core/hle/hle.cpp
@@ -47,7 +47,19 @@ void DspHle::serialize(Archive& ar, const unsigned int) {
}
SERIALIZE_IMPL(DspHle)
-static constexpr u64 audio_frame_ticks = 1310252ull; ///< Units: ARM11 cycles
+// 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
+//
+// 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
struct DspHle::Impl final {
public:
From a0e8255b656969b417e517a84e4b099727ff9d89 Mon Sep 17 00:00:00 2001
From: xperia64 <xperiancedapps@gmail.com>
Date: Sun, 26 Apr 2020 03:14:54 -0400
Subject: [PATCH 2/4] 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:
From 62e2cd62396b3ed19494e9d3ff5f4b46af9499a9 Mon Sep 17 00:00:00 2001
From: xperia64 <xperiancedapps@gmail.com>
Date: Wed, 10 Jun 2020 17:10:50 -0400
Subject: [PATCH 3/4] Use samples_per_frame instead of hardcoded 160
---
src/audio_core/hle/hle.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/audio_core/hle/hle.cpp b/src/audio_core/hle/hle.cpp
index 23a472d04..dfbc8daf0 100644
--- a/src/audio_core/hle/hle.cpp
+++ b/src/audio_core/hle/hle.cpp
@@ -54,7 +54,7 @@ SERIALIZE_IMPL(DspHle)
//
// 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
+static constexpr u64 audio_frame_ticks = samples_per_frame * 4096 * 2ull; ///< Units: ARM11 cycles
struct DspHle::Impl final {
public:
From b0a20180ee40e122d5fb23e994e564f89c07c7c4 Mon Sep 17 00:00:00 2001
From: xperia64 <xperiancedapps@gmail.com>
Date: Wed, 10 Jun 2020 23:05:02 -0400
Subject: [PATCH 4/4] Update comments after hardware testing
---
src/audio_core/hle/hle.cpp | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/audio_core/hle/hle.cpp b/src/audio_core/hle/hle.cpp
index dfbc8daf0..cba17c5ca 100644
--- a/src/audio_core/hle/hle.cpp
+++ b/src/audio_core/hle/hle.cpp
@@ -47,13 +47,11 @@ 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's suggestion
-// samples per frame * teaklite cycles per sample * 2 ARM11 cycles/teaklite cycle
+// The value below is the "perfect" mathematical ratio of ARM11 cycles per audio frame, samples per
+// frame * teaklite cycles per sample * 2 ARM11 cycles/teaklite cycle
// (160 * 4096 * 2) = (1310720)
//
-// 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
+// This value has been verified against a rough hardware test with hardware and LLE
static constexpr u64 audio_frame_ticks = samples_per_frame * 4096 * 2ull; ///< Units: ARM11 cycles
struct DspHle::Impl final {