[pulseaudio-discuss] [PATCH] protocol-native: Fix source latency calculation in ADJUST_LATENCY mode

[Arun Raghavan]

On 13 April 2015 at 18:05, Arun Raghavan <arun at accosted.net> wrote:
> On 13 April 2015 at 17:49, David Henningsson
> <david.henningsson at canonical.com> wrote:
>>
>>
>> On 2015-04-13 11:26, arun at accosted.net wrote:
>>>
>>> From: Arun Raghavan <git at arunraghavan.net>
>>>
>>> This fixes buffer attr calculation so that we set the source latency to
>>> the requested latency. This makes sense because the intermediate
>>> delay_memblockq is just a mechanism to send data to the client. It
>>> should not actually add to the total latency over what the source
>>> already provides.
>>>
>>> With this, the meaning of fragsize and maxlength become more
>>> meaningful/accurate with regards to ADJUST_LATENCY mode -- fragsize
>>> becomes the latency the source is configured for (which is then
>>> approximately the total latency until the buffer reaches the client).
>>> Maxlength, as before, continues to be the maximum amount of data we
>>> might hold for the client before overrunning.
>>
>>
>> So the current behaviour is that if you ask for 20 ms of fragsize in
>> ADJUST_LATENCY mode, then you will get packets of 10 ms each? That seems a
>> bit odd.
>
> Yup, that's exactly what is happening.
>
>> Still, I'm not so sure about this. Part of that is because we're changing
>> things that can break existing clients that rely on specific buffer
>> semantics, and part of it is, I think the reasoning that we're trying to
>
> I disagree with this one because the buffer attr semantics are not
> part of the API. I'd rather not be forced to adhere to our (imo bad)
> calculations right now for this reason. If you feel it's essential, we
> can try to mitigate the risk by requesting additional usage, making a
> lot of noise about the change, etc. but I don't think we should hold
> back on changing things that are wrong.
>
> (and yes, I know we've been bitten by this in the past with Skype, but
> that exposed a bug in Skype code, so I'd count it as being positive in
> the grand scheme of things :))
>
>> compensate for latencies in other parts of the system. I e, in order to get
>> every sample to you within 20 ms (counted from when the ADC put a sample in
>> the buffer), then you can't have 20 ms of fragsize, because then the total
>> latency would be 20 ms plus latencies in the system. Hence, we choose 10 ms
>> and gamble that the system latencies are less than 10 ms, so that the
>> samples will reach the client in time.
>
> The current math halves the requested latency blindly -- so with 200ms
> of latency, we'll end up with 100ms in software and 100ms in flight.
> It's pretty unlikely that the samples will actually spend anywhere
> near that much time in flight.
>
> We _could_ try to budget for the latency of transfer + scheduling, but
> imo this isn't too valuable, since it'll vary quite a bit between
> systems. We're talking about best effort, and not latency guarantees
> atm, so I'm okay with the inaccuracy.
>
> You did make me think of one caveat in this -- if the actual source
> latency is lower than fragsize, we'll end up passing back smaller
> chunks than requested. This isn't any worse than what we have right
> now, though, and if needed, in the future we can try to send out the
> blocks after collecting enough.

Any other opinions on this? I'd like to push this out sooner in the
7.0 cycle rather than later.

-- Arun