Comment 9 for bug 1086999

> Have you tried deriving the PID parameters from the latency? Worst-case we
> could have a set of parameters for when the latency is above a certain
> value and a set for below.
>

Here is an idea, deriving PID params based on latency is not the worst
thing, but it should be this way..

Currently we are using only P controller (and it is working quite well). If
you notice, the behavior of scratching varies across latencies. For lower
latencies system reaches the target position faster as compared to higher
latencies. And for very high latency (85.3ms) system overshoots because the
update rate of current position is slow and the corrections applied shoots
beyond the target position, hence the rubber band like behavior.

One of the things that we dont want is to over shoot the target position.
The P gain should vary with latency and error (difference between target
position and current position).
Like, if latency == 10 ms

if fabs(error) > 60000

m_p = UPPER_THRESHOLD // apply corrections aggressively

else

m_p = LOWER_THRESHOLD // slow down as we approach target value, to avoid
overshoot

This kind if thing is more required for higher latency.
On my dev box, following works well,
 if latency == 85.3 ms

if fabs(error) > 160000

m_p = 0.0002 // the current value that is being used

else

m_p = 0.00005 // slow down as we approach target value, to avoid overshoot

but I dont see this as a good solution because this will not guarantee
similar behavior across latencies, m_p should vary as (some kind of
exponential) function which depends on error and latency in use in order to
make scratching more 'consistent'

my two cents.

>
>
> On Wed, Feb 6, 2013 at 2:18 AM, Daniel Schürmann <
> <email address hidden>
> > wrote:
>
> > For me this is a 1.11.0 blocker because every new user will try at least
> > waveform scratch and hitting this bug will lead to a bad first
> > impression.
> >
> > I looks like, it can be solved by tweaking the PID controller for
> > different latency's.
> > Currently I have not managed to find a parameter set that is suitable for
> > low and high latencies.
> >
> > I am not sure yet if there is no underlying issue, but for 1.11.0 we
> > should at least get rid of the oscillation with any latancy at cost of
> > responsiveness
> >
> > @RJ: Do you have own test results for different PID setting?
> >
> > --
> > You received this bug notification because you are a member of Mixxx
> > Development Team, which is subscribed to Mixxx.
> > https://bugs.launchpad.net/bugs/1086999
> >
> > Title:
> > Rubber band like waveform scratch at high latency
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/mixxx/+bug/1086999/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to Mixxx.
> Matching subscriptions: Mixxx Dev
> https://bugs.launchpad.net/bugs/1086999
>
> Title:
> Rubber band like waveform scratch at high latency
>
> Status in Mixxx:
> In Progress
>
> Bug description:
> Due to the last change in Waveform scratch in 1.11 i have now a funny
> effect when trying to scratch with the waveform.
> Like pulling on a rubber band. It is extreme on 92 ms latency. My
> desktop system does not suffer this problem.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1086999/+subscriptions
>

--
shashank
(shanxS)

"No. Try not. Do or do not... there is no try"