-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Waveform scratch: fast oszilating track if the mouse update rate is below audio buffer size #6905
Comments
Commented by: 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.
|
Commented by: 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. I think we should take here the same approach like I have proposed for the Waveform dejerking.
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). |
Commented by: 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. 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. 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. |
Commented by: 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. For this bug this is clearly overdone. So we have to deal with the QT event queue delays :-( |
Commented by: daschuer Ok, finally I am satisfied with my current solution in lp:~daschuer/mixxx/daschuers_trunk #3161
This finally gives a much better sound during scratch then current 1.11 implementation and only a minimum response regression. You can find test builds at: |
Commented by: kain88-de 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. |
Commented by: daschuer Thank you Max, for testing! |
Commented by: daschuer Attached you find a patch against lp:mixxx/1.11 r3774 |
Commented by: esbrandt Tested with latest lp:mixxx/1.11 on OSX 10.8.3 Thanks for investigating the issue and for providing a patch. |
Commented by: daschuer Thank you for testing! |
Issue closed with status Fix Released. |
Reported by: daschuer
Date: 2013-02-06T23:35:08Z
Status: Fix Released
Importance: Low
Launchpad Issue: lp1117806
Attachments: waveform_scratch.patch
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.
The text was updated successfully, but these errors were encountered: