On Tue, 2016-08-23 at 19:53 +0200, Georg Chini wrote: > On 23.08.2016 17:47, Tanu Kaskinen wrote: > > > > I don't know whose definition is wrong, but to me "adaptive resampling" > > means just dynamically adjusting the resampling to make sure that there > > aren't buffer under- or overruns due to clock rate differences, and the > > existing code already satisfies this. Therefore, it looks wrong to me > > to say that this patch "implements adaptive resampling", as if that > > wasn't already implemented. > > > Up to this patch, it was always assumed, that source and sink are both > running with the nominal rate and there is only some difference between > target and actual latency that must be corrected. After the initial > correction > you would see some saw-tooth function of the latency, because the > controller assumes that both sampling rates are equal and only corrects > the latency when it goes out of range. So the difference between the time > domains was not considered. > This patch now tries to find the optimum sampling rate for the sink, so > that the latency remains constant by accounting for the difference between > the time domains. If this is not adaptive re-sampling, how would you > call it? I'm not saying that it's not adaptive resampling, I'm saying that the old code implemented adaptive resampling too. I'd call the change that this patch makes stabilizing the sink input rate. -- Tanu
