Comment 15 for bug 1086999

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hey Daniel,

At good latencies (between 1 and 5ms) the patch from #11 sounds really bad (the audio is garbled while scratching). This is because the rate control is too stiff w/ exponential control.

Adding a workaround for high latencies only is fine with me, but I would prefer you make a high-latency scratch controller class that modularly replaces PositionScratchController so that users with good latency are not affected by the workaround at all. Basically, instead of hacking up the PID controller code to not be a PID controller anymore, I think there should be a drop-in replacement class that is only enabled when the user has high latency.

BTW -- the patch from #11 also re-introduces Bug #779179. In the current implementation m_dLastPlaypos is used to accumulate m_dPositionDeltaSum. This essentially keeps track of "samples travelled" by the engine. The velocity controller operates on samples travelled instead of position targets because otherwise the velocity controller will go crazy when it tries to reach an absolute position that lies beyond a loop boundary. It will hit the loop boundary and get farther away from the target, which will only cause it to try even harder to accelerate towards the target which result in a feedback loop.