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.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
