It doesn't just affect me, it affects a lot of cheap or on-board sound cards. The solution is pretty simple though, just create a software sound buffer. So I thought I'd be "clever" and create a DirectSound proxy DLL. Then, when DK2 asks for a DirectSound interface, I can hand it a proxy interface, and then strip out the "create buffer in hardware" flag and force it to software. Simple, yes? Well, no.
The problem is that DK2 doesn't use DirectSound directly. It uses "QSound", which does "something" and ends up using OLE to do its dirty work. OLE takes great pleasure in making things difficult for me, by not calling DirectSoundCreate() at all, it insists on using the COM DllGetClassObject() function. That in its own wouldn't be too bad - I already have my DLL set up to intercept a DllGetClassObject() request for CLSID_DirectSound. The problem is what it does with the IDirectSound (or rather, the proxy object) pointer. The first thing it does with this pointer is call CreateSoundBuffer() on it, with a NULL buffer desc, a seemingly gibberish output interface pointer (*pointer = 0x279afa83, which is an odd value in both senses of the word), and with the COM aggregation interface non-NULL [sad]
So, I now have to learn how to do COM aggregation in order to just get my DSound interface constructed in the proper way. I have a feeling it'll be pretty simple for what I want, but it's still something I could do without. And there was me thinking this would be a one or two hour project...
So, if you know about COM aggregation, feel free to reply here or in My Thread. I'm going to bed. Joy joy joy...
