[pulseaudio-discuss] [PATCH v4] Make module loopback honor requested latency

[Alexander E. Patrakov]

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