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.
