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
