08.02.2015 18:50, Georg Chini wrote: > 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. OK, then I think there was some misunderstanding on my side. Could you please post some log lines with two USB devices to completely clear this up? I want logs without the stop criterion (which is properly called a "deadband"), and with both 0.75% and the 2â?° restraints commented out, and adjust_time of 2 seconds. Just for debugging my assumptions :) -- Alexander E. Patrakov
