[pulseaudio-discuss] [PATCH v12 01/13] bluetooth: Fix usage of MTU, buffer sizes and return values of encode/decode methods

[Tanu Kaskinen]

On Fri, 2019-07-05 at 15:02 +0200, Pali Rohár wrote:
>  /* Run from IO thread */
>  static int a2dp_write_buffer(struct userdata *u, size_t nbytes) {
>      int ret = 0;
>  
> +    if (PA_UNLIKELY(!nbytes)) {
> +        u->write_index += (uint64_t) u->write_memchunk.length;
> +        pa_memblock_unref(u->write_memchunk.memblock);
> +        pa_memchunk_reset(&u->write_memchunk);
> +        return 0;
> +    }

Is this to handle a situation where the encoder accepts input but
doesn't produce any output (the algorithmic delay thing you mentioned
in the commit message)? This can't happen with SBC, right? I think
there should be a comment explaining when nbytes can be zero.

> @@ -578,9 +592,8 @@ static int a2dp_process_push(struct userdata *u) {
>          pa_smoother_put(u->read_smoother, tstamp, pa_bytes_to_usec(u->read_index, &u->decoder_sample_spec));
>          pa_smoother_resume(u->read_smoother, tstamp, true);
>  
> -        pa_memblock_release(memchunk.memblock);
> -
> -        pa_source_post(u->source, &memchunk);
> +        if (PA_LIKELY(memchunk.length))
> +            pa_source_post(u->source, &memchunk);

I'm not sure about this. It sounds like it should be impossible that an
encoded frame results in no decoded data, so maybe an assertion would
make more sense? On the other hand, a simple check like this can't do
much harm, and if some codec indeed can return zero data, just skipping
pa_source_post() in that case seems correct.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk