[pulseaudio-discuss] [RFC][PATCH] improve missing handling in memblockq (was Re: stream wedged in non-playing state)
Arun Raghavan
arun at arunraghavan.net
Fri Jul 22 09:54:10 UTC 2016
On Fri, 22 Jul 2016, at 02:45 PM, Arun Raghavan wrote:
>
>
> On Thu, 30 Jun 2016, at 02:43 AM, Ulrich Eckhardt wrote:
> > Pierre Ossman wrote:
> > > Triggering the bug requires a specific amount of data to be drained,
> > > which is difficult to achieve in any sensible manner just by being a
> > > client. :/
> > >
> > > I added the attached test though. It doesn't test the full scope of
> > > the bug as it doesn't include the native protocol side of things, but
> > > it should verify correct minreq behaviour in the core (which in turn
> > > should avoid bugs further out).
> >
> > Hi!
> >
> > I recently tried to look at this report, too, and couldn't quite
> > understand what initially caused the issue, so I started writing tests
> > for various aspects of the memblockq code. The results so far are
> > available at https://github.com/UlrichEckhardt/pulseaudio in the
> > feature/pa_memblockq_tests branch, in case anyone wants to take a look
> > or pull them.
> >
> > There is one commit ("Add a test for missing data behaviour") there,
> > which shows an oddity in the behaviour already: If you exceed the
> > target length and then drain some data, these drained bytes are
> > reported as missing via pop_missing(), even if the current level still
> > exceeds the target length, which seems wrong.
> >
> > I also tried your attached testcase (had to adjust it slightly) and
> > could also reproduce faults with it. For convenience I uploaded it to
> > the feature/pa_memblockq_pop_missing branch there.
>
> Thanks for this, and I'll take a look at the other tests you added as
> well. I'm pushing your patch reattributed to Pierre (since the majority
> of code in there is still his), and with attribution to you in the
> comment.
I think those tests are something we should definitely add. I've pushed
all but the last which, as you pointed out, fails. Will take a look at
that now.
-- Arun
More information about the pulseaudio-discuss
mailing list