Re: mmdevapi: After GetBuffer, refuse Reset, but Start/Stop is ok.

[Andrew Eikum]

On Mon, Aug 22, 2011 at 10:56:29AM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
> My tests also show that a GetBuffer/ReleaseBuffer pair is left
> undisturbed by Stop/Start in between. Fortunately, this
> has no effect on the current code (but it shows that Stop must
> not change This->held_frames or the write_pos).

Could you add tests to render.c showing this?

Andrew

mmdevapi: After GetBuffer, refuse Reset, but Start/Stop is ok.

Hi,
> > My tests also show that a GetBuffer/ReleaseBuffer pair is left 
> > undisturbed by Stop/Start in between. Fortunately, this has no effect 
> > on the current code (but it shows that Stop must not change 
> > This->held_frames or the write_pos).
> > Could you add tests to render.c showing this?

Eventually all my tests will find their way into git, it's just that I
need time to think about how I can make them work "mostly" in Wine
without crashing and giving false results because of some bugs.
Hopefully before Friday.
It would take time too to trim my tests down to a subset that works in
current Wine.  For now the plan is to add fixes slowly until the point
where only a few todo_wine will suffice, without crashes.

You are welcome to try out some version of my tests attached to #27937, or
more current as testbot job #13483, which includes the ordering tests,
which some people on this list tested too (thank you again, guys).

BTW, the test result is not in contradiction with MSDN.

It's always the same once the tests become too elaborated.  I've a
fairly complex mcimidi testsuite which I'm not submitting yet because
I'll first have to finish some of my mcimidi patches.
todo_wine is not enough to get things working.

Actually, the reason is more subtle: adding mcimidi tests now with
lots of todo_wine and defenses against crashes would make it hard to
find an ordering of patches that always removes todo_wine instead of
temporarily adding some to tests that work by chance (or double error) rather than
design.  So it's much easier to write the tests first, then the code,
then submit the code, then the tests.  Which is what I'm doing.

Regards,
	Jörg Höhle