On 10 June 2015 at 20:59, David Henningsson
<david.henningsson at canonical.com> wrote:
> In case the sample spec is not known, as can be the case when
> pa_stream_new_extended is used, we cannot satisfy the PULSE_LATENCY_MSEC
> request.
>
> As a workaround disable being able to use PULSE_LATENCY_MSEC in this case.
>
> Reported-by: Fritsch <fritsch at xbmc.org>
> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
> ---
> src/pulse/stream.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/src/pulse/stream.c b/src/pulse/stream.c
> index d4ad505..c301b8e 100644
> --- a/src/pulse/stream.c
> +++ b/src/pulse/stream.c
> @@ -990,16 +990,18 @@ static void patch_buffer_attr(pa_stream *s, pa_buffer_attr *attr, pa_stream_flag
>
> if (pa_atou(e, &ms) < 0 || ms <= 0)
> pa_log_debug("Failed to parse $PULSE_LATENCY_MSEC: %s", e);
> + else if (!pa_sample_spec_valid(&s->sample_spec))
> + pa_log_debug("Ignoring $PULSE_LATENCY_MSEC: %s (invalid sample spec)", e);
Other than that error message needing fixing ("e" is not valid in the
else if clause), this looks fine.
I'm sending in a patch that will make this also work for the extended
API if we're using it for a single format.
I'm thinking that it might make sense to recommend that buffer attrs
be fixed up _after_ connect if the client is using the extended API
with multiple formats.
-- Arun
