Waveform scratch: fast oszilating track if the mouse update rate is below audio buffer size

[Daniel Schürmann]

In this case, the PID controller processes the same Mouse position two times and slow down the track as if it should be stopped.
In the next cycle it is speed ed up again. This effect sound very noisy.

[Daniel Schürmann (daschuer)]

here is a sniped of terminal out with the patch from Bug #1117806 at 5.8 ms Audio Buffer size and a Mouse Move with ~ normal play speed, desired rate = 1.

Debug []: continue Rate 1.16917 222400 0 1.11517e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.22901 223200 0 1.11524e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.861311 223200 0 1.11531e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.02595 224000 0 1.11536e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.21289 224800 0 1.11541e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.866452 224800 0 1.11546e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.555083 224800 0 1.11552e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.06044 226000 0 1.11555e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.28151 226800 0 1.1156e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.63685 228000 0 1.11566e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.18326 228000 0 1.11573e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.23833 228800 0 1.1158e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.867138 228800 0 1.11586e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.02946 229600 0 1.11592e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.21525 230400 0 1.11597e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.867637 230400 0 1.11602e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.795327 230800 0 1.11608e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.542255 230800 0 1.11612e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.341438 230800 0 1.11615e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.16599 232400 0 1.11618e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.921062 232400 0 1.11622e+07 1.09296e+07 512 44100
Debug []: continue Rate 1.0831 233200 0 1.11627e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.774298 233200 0 1.11632e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.973621 234000 0 1.11637e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.941278 234400 0 1.11641e+07 1.09296e+07 512 44100
Debug []: continue Rate 0.649056 234400 0 1.11646e+07 1.09296e+07 512 44100

[Daniel Schürmann (daschuer)]

You can see the oscillating rate in the first column, and the Mouse Position in the second column.

The standard Mouse polling rate is 125 Hz = 8 ms. But here we can see up to cycles up to 4 Times with the same value.
So we have a effective Mouse update rate in Mixxx of at least 23.2 ms in this case.
With 23.2 ms Audio Buffer size you have still the noise sound but with 46.2 ms the crach sound becomes clean.

I think we should take here the same approach like I have proposed for the Waveform dejerking.
* Bypassing the control objects.
* Storing the mouse samples with a time stamp
* calculate the Missing samples as required.

This way we are also able to solve bug Bug #1117806

For extra benefit it would be nice if we can hock up directly into the mouse polling task to have the pure 125 hz update rate within Mixxx or higher rates of some gaming mice (up to 1000 Hz).

[Daniel Schürmann (daschuer)]

I have tried to nailed it down for X11:

For a super smooth waveform scratch we need a constant mouse sample rate, best at audio buffer size.
All X11 mouse events are timestamped, so in theories we could achieve this with X11.

Unfortunately the mouse is handled by Qt in the not real time GUI Thread and the time stamp is lost on the way to mixxx. So we may facing unknown but significant delays if Mixxx is busy with other tasks in GUI thread.
An other problem is, that there is no MouseStop event. We are not able to distinguish mouse movement stops from delayed MouseMove event.

I think a solution for now is to calculate the missing samples from the previous rate for about 23 ms. The resulting overshoot in case of stops or rate decrees should be ironed out by the following velocity controller.

[Daniel Schürmann (daschuer)]

I have tried to user QCursor::pos() from the engine thread. First I looks very promising, but it turn out that it is a locking function which is not suitable for the engine thread.
http://www.spinics.net/lists/xorg/msg53502.html
Proposed solution from this thread: using XCB!
http://xcb.freedesktop.org/

For this bug this is clearly overdone. So we have to deal with the QT event queue delays :-(

[Daniel Schürmann (daschuer)]

Ok, finally I am satisfied with my current solution in lp:~daschuer/mixxx/daschuers_trunk #3161

Changes:
* Transfer the Mouse position via Qt event and a single global (pfui ;-)) to engine thread
* equalize sample time by reading the mouse position after at least 16 ms
* Introduce an IIR lowpass to iron the error = key
* Disable the IIR for decreasing errors
* Control the rate by a PD Controller with negative d
* Ignore Mouse stops for 0,4 ms
* detect initial Mouse stop and stop immediately in this case
* start with a settled controller

This finally gives a much better sound during scratch then current 1.11 implementation and only a minimum response regression.
You can test best with a 1Khz Tone or a vocal track trying to scratch with rate = 1.
I have experienced big differences in the mouse signal quality during test. My parameters are tweaked with different pointer devices but tested only with Ubuntu.

You can find test builds at:
http://builds.mixxx.org/builds/experimental-daschuers_trunk/r3161/
soon.

[Max Linke (max-linke)]

Your version sounds better then release-1.11.x/r3771 using a 1Khz sine on win7 64bit

And I can hear an oscillation in trunk compared to not noticeable with you patch.

[Daniel Schürmann (daschuer)]

Thank you Max, for testing!
Is the response regression acceptable?

[Daniel Schürmann (daschuer)]

Attached you find a patch against lp:mixxx/1.11 r3774
I have removed the CO bypass because I am working on a general solution.
The patch fixes also Bug #1117762.

[jus (jus)]

Tested with latest lp:mixxx/1.11 on OSX 10.8.3
Most noticeable when doing slooow drags, the sound is more clean then with the current implementation.
Re:#7 To me, there is no significant regression in the response.

Thanks for investigating the issue and for providing a patch.

[Daniel Schürmann (daschuer)]

Thank you for testing!
Committed to lp:mixxx 1.11 revision 3776.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6905