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

[David Henningsson]

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.

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 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.

Does that make sense?

> ---
>   src/pulsecore/protocol-native.c | 19 ++++++++++---------
>   1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/src/pulsecore/protocol-native.c b/src/pulsecore/protocol-native.c
> index adb5877..a5f4e23 100644
> --- a/src/pulsecore/protocol-native.c
> +++ b/src/pulsecore/protocol-native.c
> @@ -568,11 +568,14 @@ static void fix_record_buffer_attr_pre(record_stream *s) {
>       } else if (s->adjust_latency) {
>
>           /* So, the user asked us to adjust the latency according to
> -         * what the source can provide. Half the latency will be
> -         * spent on the hw buffer, half of it in the async buffer
> -         * queue we maintain for each client. */
> +         * what the source can provide. We set the source to whatever
> +         * latency it can provide that is closest to what we want, and
> +         * let the client buffer be equally large. This does NOT mean
> +         * that we are doing (2 * fragsize) bytes of buffering, since
> +         * the client-side buffer is only data that is on the way to
> +         * the client. */
>
> -        source_usec = fragsize_usec/2;
> +        source_usec = fragsize_usec;
>
>       } else {
>
> @@ -598,12 +601,10 @@ static void fix_record_buffer_attr_pre(record_stream *s) {
>
>       } else if (s->adjust_latency) {
>
> -        /* Now subtract what we actually got */
> +        /* We keep the client buffer large enough to transfer one
> +         * hardware-buffer-sized chunk at a time to the client. */
>
> -        if (fragsize_usec >= s->configured_source_latency*2)
> -            fragsize_usec -= s->configured_source_latency;
> -        else
> -            fragsize_usec = s->configured_source_latency;
> +        fragsize_usec = s->configured_source_latency;
>       }
>
>       if (pa_usec_to_bytes(orig_fragsize_usec, &s->source_output->sample_spec) !=
>

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic