The state of IDirectSoundBuffer
mstefani at redhat.com
Mon Aug 29 07:53:51 CDT 2011
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
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
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
- 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:
- Once all methods are converted I'll switch the primary buffer to use
the same vtbl.
More information about the wine-devel