Sync Controller polling with audio buffer (Latency)

[mixxxbot]

Reported by: daschuer
Date: 2013-03-20T07:29:43Z
Status: New
Importance: Wishlist
Launchpad Issue: lp1157579
Tags: controllers, hid, midi, performance

---

As discussed in Bug #⁠990992 we are not satisfied with the controller responds vs. CPU load.

I think this issue matters only the wheel, especially if we want to have benefit from the high resolution wheels.

IMO it would be the best solution to sync the controller polling with the audio callback.
So the most time critical controls are effecting the rate of the track. Problems here are leading to Bug #⁠1117806

This is calculated during from the audio callback thread.
So for best responsibility we have to achieve that all Controller messages are processed just before.
All messages from on audio cycle can processed at once. so there is no need to have higher polling frequency for Midi.
On the other hand if you are able to run at low audio latencies, a fixed polling frequency may to slow so that there are always audio cycles without any control changes.

Fortunately PortMidi delivers the midi messages with a time stamp so a timed service at driver accuracy is possible as addition even with long polling intervals see Bug #⁠1157573

[mixxxbot]

Commented by: daschuer
Date: 2013-03-20T07:49:34Z

---

A other issue pro this solution is the waveform dejerking.
Every timer driven thread that may not yield the GUI thread for rendering results into a waveform jerk.

[mixxxbot]

Commented by: daschuer
Date: 2015-01-22T07:58:12Z

---

http://www.mixxx.org/forums/viewtopic.php?f=1&t=6879

[JoergAtGithub]

The problem is fixed for HID in: #4585
But syncing with the audio buffer wasn't the solution for HID, because all HIDAPIs IO commands are blocking and must all run in the same thread. Instead the readout of the InputReport ring buffer of the OS is triggered by the completion of the OutputReport write operation. The CPU usage for HID IO is no longer significiant after this change.