mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
a49268f1a0
Enable Time Stretching read true on the device, though upstream defaults it false, Settings writes ps3.audioTimeStretch which is false, and no core override touches it. Something later was setting it back. Six PCSX2 keys reach RPCS3 nodes that a PS3/ key already owns: Enable Time Stretching <- SPU2/Output/SyncMode Desired Audio Buffer Duration <- SPU2/Output/OutputLatencyMS Enable Buffering <- SPU2/Output/BufferMS Anisotropic Filter Override <- EmuCore/GS/MaxAnisotropy Clocks scale <- Framerate/NominalScalar Frame limit <- EmuCore/GS/SyncToHostRefreshRate They date from before the PS3/ pseudo-sections existed, which were added for exactly this reason. Being unambiguous in the bridge was not enough: put() calls setSetting immediately rather than collecting into a map, so applyTo's source order is the call order, and every PS3 write lands first (L939-994) with the PCSX2 one later (L1044-1765). The leftover won every time. The field each UI row is bound to is the PS3 one in all six cases; the PCSX2 counterparts appear only in the reset-fields list or nowhere. So the Audio tab's Time Stretching toggle did nothing at all: it wrote false, and SyncMode wrote true ninety lines later. Two were independently wrong. BufferMS turned a buffer size in milliseconds into the boolean "buffering enabled". SyncToHostRefreshRate mapped to Frame limit "Display", which resolves to the host panel's refresh, so on a 120Hz handheld it asked for a 120fps cap, the same mistake just fixed in setDisplayRefreshRate; and its `if (asBool(value))` guard could only ever set the mode, never clear it, so turning the setting off left the cap in place. All six now fall through to the unhandled path. Verified no RPCS3 setter is left with more than one writer.