[pulseaudio-discuss] [PATCH 04/13] loopback: Adjust rates based on latency difference

[Alexander E. Patrakov]

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:
>>
>> http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
>> http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
>>
> 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 
whole.

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 
differences.
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 
forward.
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