Update cycles and explanation
This commit is contained in:
parent
3a1601a534
commit
a0e8255b65
1 changed files with 6 additions and 11 deletions
|
@ -48,18 +48,13 @@ void DspHle::serialize(Archive& ar, const unsigned int) {
|
||||||
SERIALIZE_IMPL(DspHle)
|
SERIALIZE_IMPL(DspHle)
|
||||||
|
|
||||||
// TODO(xperia64): The value below is the "perfect" mathematical ratio
|
// TODO(xperia64): The value below is the "perfect" mathematical ratio
|
||||||
// of ARM11 cycles per audio frame. As per merry, this was calculated to be
|
// of ARM11 cycles per audio frame, as per merry's suggestion
|
||||||
// (ARM11 freq)*(samples per frame)/(sample rate)
|
// samples per frame * teaklite cycles per sample * 2 ARM11 cycles/teaklite cycle
|
||||||
// = (268,111,855.956 Hz) * (160 samples)/(32,728 Hz)
|
// (160 * 4096 * 2) = (1310720)
|
||||||
// = (1310739.946008311...) ~ 1310740
|
|
||||||
//
|
//
|
||||||
// This value was originally set to 1310252, which was determined by measuring it on hardware
|
// As per merry, it may be useful to verify this on hardware with the more recently
|
||||||
// However, as of when this was written, Project Mirai 1/2/DX desync on HLE
|
// discovered "correct" ARM11 frequency of 268111856 as opposed to 268123480
|
||||||
// such that the music track runs ahead of the gameplay.
|
static constexpr u64 audio_frame_ticks = 160 * 4096 * 2ull; ///< Units: ARM11 cycles
|
||||||
// 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 {
|
struct DspHle::Impl final {
|
||||||
public:
|
public:
|
||||||
|
|
Loading…
Reference in a new issue