On 08.02.2015 14:03, Alexander E. Patrakov wrote: > 08.02.2015 17:35, Georg Chini wrote: >> >>>> I think there is some misunderstanding. Let me repeat in a different >>>> way. >>>> >>>> The smoother works perfectly (both for timer-based scheduling and for >>>> the needs of your module) on non-batch cards. >>>> >>>> But, even for batch cards, where timer-based scheduling is disabled, >>>> the smoother is active and is actually used for reporting the latency >>>> to your module. An attempt to use the smoother for timer-based >>>> scheduling on batch cards has failed. That's why I suspect that it, >>>> on batch cards, also tells lies to your module. >>> >>> OK, understood. I don't have anything to test it though >> >> Mh, are my USB devices batch cards? I just noticed it says "Disabling >> timer scheduling >> because BATCH flag is set" in the log and I am not sure, what a batch >> card is. > > Yes, your USB devices are batch cards. This means that they don't > report their playback position accurately enough. For USB devices, the > granularity of position reports is 6 ms (for large period sizes), but > for others, it may be up to one period size. > When I understand you right, this means that the error of the latency report will be in the range of the granularity, so latency may jump around within the bounds of this error. Then you definitely need a stop criterion and my approach is correct because it measures the error of the latency report and uses that to stop regulation when you are within those bounds. To give you an impression how it works on batch cards: With an adjust_time of 2 seconds, 44100 Hz sample rate and the default fragment size of 25 ms you usually end up with about +/-1 ms error, which is better than I would expect from your statement above. But I am also seeing some drift, that means that the regulator will do some small correction every few adjust_times. I do not know if this drift is real or caused by the smoother. I will look into it and see if I can work around the smoother.
