[pulseaudio-discuss] [PATCH 00/13] loopback: Make module-loopback honor requested latency (v5)

[Alexander E. Patrakov]

19.11.2015 21:47, Alexander E. Patrakov wrote:
> 19.11.2015 11:48, Georg Chini wrote:
>> On 19.11.2015 05:08, Alexander E. Patrakov wrote:
>>> 19.11.2015 00:43, Georg Chini wrote:
>>>> On 15.11.2015 22:08, Alexander E. Patrakov wrote:
>>>>> However, I'd argue that this phase metric can be improved without the
>>>>> deadband and beyond what this deadband-based implementation provides.
>>>>>
>>>>
>>>> What is the problem with the dead band? There are physical limitations
>>>> to what makes
>>>> sense to correct and the dead band just takes care of those limits.
>>>
>>> There are no such limits once you (or your second-order filter) start
>>> averaging previous latency difference measurements.
>>
>> You are definitely wrong there. This would only be (nearly) true, if the
>> error of the latency
>> measurement would be small. In practice it isn't and even the best low
>> pass filter
>> will not remove all of the error. Take a look at the latency error
>> values that my
>> code provides. It already is a low pass filtered value.
>
> I can, so far, only make a conclusion that I should try a different
> lowpass filter.
>
>> Especially in the first couple of seconds you do not get very reliable
>> values. There
>> must be something in pulseaudio which is preventing that. Maybe it is
>> the time
>> smoother that has to settle down. I think you can also see this effect
>> in the images
>> of the original recording - the phase is drifting during the first 50
>> seconds and
>> then it is nearly constant.
>
> The phase is drifting because the original latency is too far from the
> desired one. Nonzero latency difference => nonzero rate adjustment as
> compared to the ideal value => phase drift. Or, as phase is directly
> proportional to the latency, it's just the "correction of the big
> initial latency difference" process. So, my plots indeed show how fast
> or how slow the rate controller deals with such bad initial conditions.

Well, after a second look at the plots, I do notice something unusual. 
On the plots where I started the sine wave shortly after loading the 
module (instead of waiting), it can be seen that the initial phase is 
suspiciously close to zero, while my scripts set it to zero at the end. 
So the whole peak looks unnecessary (as if there is some "garbage in" 
coming from other parts of PulseAudio when estimating the latency).

-- 
Alexander E. Patrakov