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

[Georg Chini]

On 11.11.2015 22:15, Alexander E. Patrakov wrote:
> 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.

Well, this is true for my controller as well, as long as you are in a 
steady state the constraints
are never hit and it acts as a simple P-controller.

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

I disagree here. Your approach would double the audio disruptions 
because for each xrun
you would have another event where samples are dropped/inserted. It is 
the goal of the
controller to minimize such disruptions, so it should be able to handle 
latency jumps gracefully.

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

Apart from measuring the latency often (which is a good idea), what is 
the advantage of correcting
it slowly?

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

Constructions like high order filters are CPU consuming and introduce 
significant delays.
Is there really a practical advantage over the deadband? I think that 
the need to "correct
slowly" mentioned above arises from the use of a good lowpass.

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

For me this is very important because it is the way large latency 
differences are handled.
The non-linearity introduced by min_cycles ensures that the rate 
difference is kept within
bounds.