On 16.02.2017 13:10, Georg Chini wrote:
> On 16.02.2017 12:59, Tanu Kaskinen wrote:
>> On Fri, 2017-02-10 at 14:38 +0100, Georg Chini wrote:
>>> Hi,
>>>
>>> during my work on module-loopback I came upon an issue regarding the
>>> handling
>>> of the port latency offsets.
>>> The functions pa_{source,sink}_get_latency_within_thread() return the
>>> latencies
>>> including the offset. Those functions are used to determine the amount
>>> that has
>>> to be rewound during a sink move and also to calculate the time a
>>> volume
>>> change
>>> is delayed.
>>>
>>> I think it is wrong in those situations to include the offset,
>>> especially if a user sets
>>> very large or very negative offsets. If you have a large negative
>>> offset
>>> for example,
>>> the sink will never be rewound on a move because
>>> get_latency_in_thread()
>>> always
>>> returns 0. If the offset is large and positive, you might end up
>>> rewinding too much,
>>> although this is limited by max_rewind.
>>> A similar thought applies to the delay of the volume changes, although
>>> it is surely
>>> less critical there.
>>>
>>> Am I right or do I miss something?
>> You're right. The total latency is not the same thing as the rewindable
>> amount. I think there's a FIXME comment about this somewhere in the
>> stream moving code.
>
> Could this not be fixed quite easily by subtracting the offset again
> in these places? Should I send a patch?
>
>
I just noticed that this is only possible after the loopback patches
have been merged,
because they change the behavior of the
pa_{source,sink}_get_latency_in_thread()
functions ...
