[pulseaudio-discuss] [PATCH 07/13] loopback: Refactor latency initialization

[Georg Chini]

On 26.11.2015 08:41, Georg Chini wrote:
> On 26.11.2015 01:49, Tanu Kaskinen wrote:
>> On Wed, 2015-11-25 at 22:58 +0100, Georg Chini wrote:
>>> On 25.11.2015 19:49, Tanu Kaskinen wrote:
>>>> On Wed, 2015-11-25 at 16:05 +0100, Georg Chini wrote:
>>>>> On 25.11.2015 09:00, Georg Chini wrote: I am not really sure where 
>>>>> this discussion
> is leading to. We are also mixing up different topics at the moment.
> The first one is a matter of the safeguards. As already said in a
> previous mail, in my opinion those safeguards only have to cover
> the most common cases and do not need to be perfect because
> the controller will take care at runtime.

Let's pick up the safeguard discussion again. Maybe there is a reasoning,
based on your calculations in the previous mails. As far as I can tell, we
are talking about 3 different cases:

1) Interrupt driven alsa device

I would propose to accept that for this kind of device the buffer_latency
needs to be one default-fragment-size + some safety margin. This is a
value proven in practice and when I remember correctly you reason in
another mail that it could indeed fit in that special case.

2) timer based alsa device

I arrived at the conclusion that buffer_latency has to be 0.75 * 
sink_latency.
Would it be reasonable to argue that we have to keep one configured sink
latency of audio around on the source side? If yes, it would make clear 
where
that 0.75 factor is coming from.
The correct value for buffer_latency would then be
buffer_latency = configured_sink_latency - 0.25 * configured_source_latency
which gives 0.75 * configured_sink_latency if both are equal.

3) the general case, so none of the above

This is still unclear. As far as I understand, in this case there will never
be timer based scheduling. Am I correct? If yes, it can be distinguished
from case 1) just by checking the name of the device.
In this general case we probably have to choose very conservative
settings as we don't know exactly how the device will behave.

If source and sink are of different device type we have to take the
larger value.