[pulseaudio-discuss] [RFC][PATCH] improve missing handling in memblockq (was Re: stream wedged in non-playing state)

[Arun Raghavan]

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.

Cheers,
Arun