Hello guys,
my tests: - http://source.winehq.org/patches/data/78080 - http://winetestbot.winehq.org/JobDetails.pl?Key=13790 - http://winetestbot.winehq.org/JobDetails.pl?Key=13791 - http://winetestbot.winehq.org/JobDetails.pl?Key=13792 - http://winetestbot.winehq.org/JobDetails.pl?Key=13793 show that native dsound has only one IDirectSoundBuffer implementation. That shouldn't matter as per the COM rules that is an implementation detail but there are broken apps out there (http://bugs.winehq.org/show_bug.cgi?id=28207) that rely on that fact.
Not sure how many of the crashes due to dsound http://bugs.winehq.org/buglist.cgi?cmdtype=runnamed&namedcmd=dsound can be traced to that as PrimaryBufferImpl and IDirectSoundBufferImpl had (before my dsound changes) only the first three fields in common. Well PrimaryBufferImpl has only three fields as it stores its info in its parent object aka the device (this is a very common "design" in our dsound).
Keeping the two objects/implementations in sync is brittle and will litter the code. Thus my goal is to merge PrimaryBufferImpl into IDirectSoundBufferImpl. My plan of battle is (to keep the patches small and limit the scope of the regressions I'll introduce during this): - Make the primary buffer use struct IDirectSoundBufferImpl.
- Move fields that belong to the primary buffer out of struct DirectSoundDevice. The structs DirectSoundDevice and IDirectSoundBufferImpl share quite a few fields.
- For methods that have the same implementation I'll use the IDirectSoundBufferImpl_<Method>
- Methods that differ considerably between primary and secondary buffer I'll make IDirectSoundBufferImpl_<Method> just a wrapper that calls out into the respective implementation, something along the lines of: if(is_primary) return primarybuffer_<method>(...); else return secondarybuffer_<method>(...);
- Once all methods are converted I'll switch the primary buffer to use the same vtbl.
- Profit!
Comments? bye michael