[pulseaudio-discuss] [PATCH 04/13] loopback: Adjust rates based on latency difference
Alexander E. Patrakov
patrakov at gmail.com
Wed Nov 11 13:15:45 PST 2015
12.11.2015 01:24, Georg Chini wrote:
> On 11.11.2015 20:30, Alexander E. Patrakov wrote:
>> Note: I did not say that following this method is good for our
>> purposes. The PID controller recommended in these papers (and used in
>> Jack) is not optimal in the sense of Ziegler-Nichols method:
> Hi Alexander,
> regarding your note: I was under the impression that we agreed that we
> could both not
> come up with a better way of controlling the latency in this context.
Well - technically yes. However, since then, I have reevaluated the
papers, and want to express my new opinion regarding the patch set as a
You have explained why limiting the rate change (i.e. doing the
adjustment in the small steps) is incompatible with aiming to correct
the whole difference, and invented the non-linear expression for
min_cycles to avoid the problem (successfully). However, it is based on
the following assumptions:
1. Doing the adjustment in the small steps is actually desired.
2. Doing rate adjustment is indeed the way to deal with large latency
3. Correcting as much latency difference as possible in one step (unless
it conflicts with the constraints on the rate change) is indeed the way
4. Large values of adjust_time have to be supported at all.
Jack questions these assumptions, as follows:
1. For correcting reasonable latency differences, there is just no need
to make big changes of the rate. I.e. the constraint mentioned in the
comment is never hit in the steady state and thus is not necessary.
2. For correcting unreasonable latency differences (and they can appear
only after an xrun or initially), one can drop samples or insert silence
as appropriate. No need to change the rate temporarily.
3, 4. Jack measures the latency difference often (with a good side
effect of averaging out any error and jitter), but corrects it slowly.
This means it does not use a PID controller optimal in the sense of
Ziegler-Nichols, and that's why the note quoted above.
Also note that Jack has no deadband - it uses a good lowpass filter (of
4th order, instead of your 0th order filter) and thus does not need it
even for USB cards.
But also I understand that perfect is the enemy of the good. So I
neither ACK nor NACK the patches in the current form. But if you
implement (2) and either demonstrate that the non-linear term is still
needed even for an aggressive definition of "unreasonable" latency
difference, or eliminate it, then I promise to review the updated
patches. Anyway, if Tanu accepts them as they are, this is a potential
improvement that can be done on top of that.
> And - as another side
> note - my controller is only optimal in the sense of Ziegler-Nichols for
> small latency differences.
I agree with this note, but for me (due to considerations above, and
also purely subjectively) it is not very important.
Alexander E. Patrakov
More information about the pulseaudio-discuss