[pulseaudio-discuss] [RFC][PATCH] improve missing handling in memblockq (was Re: stream wedged in non-playing state)
pulseaudio at base-42.de
Wed Jun 29 21:13:36 UTC 2016
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).
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!
More information about the pulseaudio-discuss