22.11.2015 21:57, Georg Chini wrote:
> On 22.11.2015 16:05, Alexander E. Patrakov wrote:
>> 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.
>
>
> So one second silence after loading the module? Sounds rather long to me.
Well - that was just a proposal, feel free to ignore.
> And what should happen in case of an underrun?
Detect it, do not try to pretend that there was no underrun. I.e. insert
silence. Again - this is just a proposal.
> Be aware, that the "slow and good" controller ONLY accounts for the
> clock drift,
> that means it does not care about the steady state latency. Still the
> other controller
> is required to set the requested value.
That's true for your controller. For my PI-controller, the following is
true:
* It does care about steady state latency.
* It will try to completely eliminate any residual latency error, even
if there is drift.
* It will do so slowly, just fast enough to eventually correct the drift.
The other ("emergency") controller is required if we do not want to wait
for my controller to bring the latency to the desired value (and we
don't want to wait, indeed).
> Also a "slow and good" controller cannot handle sudden latency changes
> caused
> by underruns very well, so you will need some "emergency" controller to put
> things right in that case (at least if you don't want to insert silence
> or drop samples).
Same as my statement above - i.e. agreement.
--
Alexander E. Patrakov
