EdnunpandClaude Opus 5
2f702e9880
Answers Ed's "and adjusting ASIO latency also happens quickly now?" with a measurement rather than an assertion, and without needing an ASIO device: wires the engine as BothIndependent with only the ASIO lane active, confirms the stream lands on AsioLane, and drives the raise/lower through the ASIO slider's own route. Measured: 54ms -> 289ms within 10s, holds at the 330ms target, lower back to 30ms within 3s — the same fast approach as the single slider, as expected (one hard-setter path feeding whichever lane the moved slider owns). No product change; harness only. The shipped v5.9 build is untouched. Also made the harness faithful to the 5.9 arming change (NoteFramesQueued against the session's own route target, not the engine-wide one) so the ASIO case arms the way the app does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
19 lines
778 B
Plaintext
19 lines
778 B
Plaintext
RemSound latency lab - measuring depth-target convergence with the shipped playout code.
|
|
Raise under test: 30ms -> 330ms. Expected growth at full depth-bias: ~3ms/s.
|
|
|
|
--- T4 ASIO lane (two-slider mode): ASIO slider drives an ASIO-lane stream ---
|
|
session route after arrival: AsioLane (slider writes to: AsioLane)
|
|
settled at slider 30ms: buffered=54ms
|
|
t+10s buffered= 289ms
|
|
t+20s buffered= 308ms
|
|
t+30s buffered= 311ms
|
|
t+40s buffered= 303ms
|
|
t+50s buffered= 322ms
|
|
t+60s buffered= 299ms
|
|
RAISE via slider: 54ms -> 299ms in 60s = 4.08ms/s GROWS (slider works)
|
|
LOWER via slider: back to 30ms -> buffered=30ms after 3s
|
|
|
|
|
|
=== SUMMARY ===
|
|
T4 ASIO lane (two-slider mode): ASIO slider drives an ASIO-lane stream: raise 4.08ms/s [GROWS (slider works)], lower -> 20ms
|