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

[Arun Raghavan]

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.

Cheers,
Arun