The state of IDirectSoundBuffer

Michael Stefaniuc mstefani at
Mon Aug 29 07:53:51 CDT 2011

Hello guys,

my tests:
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
( that rely on that fact.

Not sure how many of the crashes due to 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

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:
        return primarybuffer_<method>(...);
        return secondarybuffer_<method>(...);

- Once all methods are converted I'll switch the primary buffer to use
  the same vtbl.

- Profit!


More information about the wine-devel mailing list