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

[Ulrich Eckhardt]

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.

Greetings from Hamburg!

Uli