[pulseaudio-discuss] [PATCH] protocol-native: fix bytes-to-usec conversion of "on-the-fly" data

[Arun Raghavan]

On Mon, 17 Jul 2017, at 10:17 PM, Tanu Kaskinen wrote:
> On Sat, 2017-07-15 at 11:20 +0530, Arun Raghavan wrote:
> > 
> > On Tue, 11 Jul 2017, at 11:46 PM, Tanu Kaskinen wrote:
> > > The on_the_fly_snapshot variable contains the amount of bytes that has
> > > been sent from the source IO thread to the main thread, but not yet
> > > pushed to the stream memblockq. The data is in the stream format, but
> > > the bytes-to-usec conversion used the source format, which caused random
> > > latency reporting errors.
> > > 
> > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=81075
> > > ---
> > >  src/pulsecore/protocol-native.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/pulsecore/protocol-native.c
> > > b/src/pulsecore/protocol-native.c
> > > index 266b676de..d5d032950 100644
> > > --- a/src/pulsecore/protocol-native.c
> > > +++ b/src/pulsecore/protocol-native.c
> > > @@ -2922,7 +2922,7 @@ static void command_get_record_latency(pa_pdispatch
> > > *pd, uint32_t command, uint3
> > >      pa_tagstruct_put_usec(reply, s->current_monitor_latency);
> > >      pa_tagstruct_put_usec(reply,
> > >                            s->current_source_latency +
> > > -                          pa_bytes_to_usec(s->on_the_fly_snapshot,
> > > &s->source_output->source->sample_spec));
> > > +                          pa_bytes_to_usec(s->on_the_fly_snapshot,
> > > &s->source_output->sample_spec));
> > >      pa_tagstruct_put_boolean(reply,
> > >                               pa_source_get_state(s->source_output->source)
> > >                               == PA_SOURCE_RUNNING &&
> > >                               pa_source_output_get_state(s->source_output)
> > >                               == PA_SOURCE_OUTPUT_RUNNING);
> > > -- 
> > 
> > Looks good. Let's get this into 11.0, maybe?
> 
> Ok, I'll push this to master. Would you like to have also
> 
>     simple: Change latency estimation to account for already-read data
>     in pa_simple_get_latency().
> 
> and
> 
>     simple: fix negative latency handling
> 
> in 11.0? Those improve latency reporting for the simple API.

I thought about that, and if you're confident there's no chance of
regressing there, maybe a freeze exception is okay.

-- Arun