Sync Controller polling with audio buffer (Latency)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mixxx |
New
|
Wishlist
|
Unassigned | ||
Bug Description
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
| Daniel Schürmann (daschuer) wrote | #1 |
| Changed in mixxx: | |
| importance: | Undecided → Wishlist |
| tags: | added: controllers performance |
| tags: | added: hid midi |
| Daniel Schürmann (daschuer) wrote | #2 |
| Swiftb0y (swiftb0y) wrote | #3 |
| lock status: | Metadata changes locked and limited to project staff |
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.