[pulseaudio-discuss] [PATCH 07/13] loopback: Refactor latency initialization

[Alexander E. Patrakov]

22.11.2015 18:44, Georg Chini wrote:
> On 22.11.2015 14:26, Alexander E. Patrakov wrote:
>> 22.11.2015 17:21, Georg Chini wrote:
>>> The other big problem is that you cannot determine the number
>>> of cycles you will need to correct the initial latency error because
>>> this error is unknown before the first adjustment cycle.
>>
>> You can circumvent this problem by sending zeros instead of the actual
>> data until you correct the initial latency error well enough. And,
>> because we are sending zeros, nobody cares if there are big frequency
>> steps. So one cycle is always enough to correct the initial latency
>> error once it is known, and then we can unmute the sound.
>
> I do not understand what you are proposing. Are you saying we should
> skip samples
> until we are near the requested latency? So send no audio for at least
> one adjust time?
> That would mean that you have to reduce the adjust time drastically.
> BTW, I did some experiments with shorter adjust times and could not see
> a significant
> improvement over the 1s interval.

Not "send no audio", but "send silence of the same length as input, and 
get it resampled".

Yes, this means that adjust_time has to be at most 1s.

>
>>
>>> When you calculate that safety margin you also have to consider
>>> that the controller might overshoot, so you temporarily could
>>> get less latency than you requested.
>>
>> This is definitely impossible with the controller in PATCH 04/13
>> modified so that min_cycles is always 1. Indeed, by design, such
>> controller corrects exactly 100% of the latency error in one step,
>> without paying attention that it might be noticeable. And with
>> min_cycles > 1, it corrects less than 100% of the error, so cannot
>> make the situation any worse than it is. I.e. here overshoot would
>> mean correcting less than 0% or more than 100% of the error, and it
>> just can't happen.
>>
>
> In theory yes, but practice you are wrong here. It does overshoot
> sometimes, especially
> with long adjust times because we are taking measurements that have some
> error.
> Consider that the measured latency is 2 ms too long (this can easily
> happen in the first cycles),
> then you will correct 2 ms too much. With short latencies, even half a
> millisecond might
> be significant.

That's only a problem for your P-controller that corrects 100% of the 
measured latency error (which is, as you have illustrated, not the same 
as the real latency error) in one step. It is a good controller for 
emergencies, but for normal operation we do need something different, 
and you have already implemented that.

You first invented some "deadband" code that switches to a very dumb 
controller that does not correct anything - but even that was better 
than the emergency controller for the steady state. Then you sent a 
private patch that estimates the clock drift, thus essentially turning 
the "deadband" code into something that decides between the old 
(emergency) and the new (slow and good) controller.

>
>> OTOH, the PI-controller that I am currently working on can indeed
>> overshoot. I think a good idea would be to detect situations where the
>> latency error is excessive or would be excessive during the next step,
>> and correct this situation with your controller with min_cycles = 1,
>> instead of my controller. That's, without paying attention to artifacts.
>>
>> I will post this controller (and, as requested, perform measurements
>> with the trivial resampler) in the near future.
>>
> Thanks, please also test the patch I sent on Friday.

With trivial resampler: https://imgur.com/a/z6oOY
With speex-float-5: https://imgur.com/a/dOIRc

In both cases, adjust_time=1. No definite conclusions until I compare 
this with my PI-controller, but both plots look similar to me, and have 
phase jitter of approximately the same scale as in 
https://imgur.com/a/eZT8L, but more smooth.

-- 
Alexander E. Patrakov