Use a small PortAudio user-buffer size regardless of host latency.

[Sean M. Pappalardo]

I just discovered that, even though I chose 2ms in the preferences, PA reports that I'm actually getting 14ms. But _the GUI controls are still more responsive_ than if I choose 11ms, still getting 14 on the audio. While we wait for the control system redesign, can't we just force the latency value low for those GUI and input elements that are inextricably tied to it? (Ideally create separate AudioLatency and GuiLatency values.)

[Daniel Schürmann (daschuer)]

As proposed in https://bugs.launchpad.net/mixxx/+bug/884705 #19,
I would set the "Audio Buffer Size" in preferences.
It is actual a "GUI latency" but the GUI Latency depends on additional things, so I would not use this term.

[Daniel Schürmann (daschuer)]

Actually we configure the "control latency" by setting the audio buffer size.
Processing the audio buffer is a high priority tasks. So processing the controls will be always done between the callback calls of the audio buffer. All new control commands are adopted earliest in the new audio buffer cycle.

The moment you will here the control effect, depends on the sum of latency of the whole controller - audio chain.
Port Audio tries the best to offer a minimum latency for the given audio buffer size.

One may want to configure a shorter interval of callback calls and have a bigger Audio Buffer inside Port audio for the same latency.
I Think this is not required, so we may treat this bug a solved by the patch attached to Bug #884705.

@Sean: do you agree? Or is it worth to add a additional "Desired Latency" configuration?

[Daniel Schürmann (daschuer)]

As discussed in Bug #1086999. We may divide that audio buffer into smaller chunks of user buffer to gain a better responsiveness for control commands.

I am not sure if it is worth to do the work because this will not gain additional processing time.

Currently we have the time for one buffer cycle. The buffer size must be bigger than this time. The buffer size can be tweaked by the user until he gets buffer underflows, because the buffer cycle is longer than the audio it that is processed.

The time for a buffer cycle is the sum of processing one sample multiplied with the audio buffer plus the time for calculating the effects of the controls since the last cycle.

If we now introduce a user buffer, lats say at the half from the audio buffer, we need the double of time for calculating controls and the same time for calculating the audio. So the over all processing time of one audio buffer grows. This requires a bigger audio buffer to prevent underflows.

This is a theoretical view. But you see that we have to be careful if the additional effort for a user buffer is worth.

[Swiftb0y (swiftb0y)]

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