Hey, so I'm wondering what the flag DSBCAPS_GETCURRENTPOSITION2 actually does. It says it fixes issues with getting the PlayPosition on emulated sound cards.

What is a Emulated Sound Card. I know DirectSound is emulated over WASAPI, so does this mean DirectSound would be using a emulated sound card, and if so should we be using this flag?

This flag exist for compatibility reasons in old apps. They may expect for DirectSound API to behave in specific way. It deals with differences between hardware and emulated devices.

Before Window Vista DirectSound could access your sound card directly - all the buffers and most API calls interacted directly with hardware. Depending whether DirectSound opened real or emulated sound card, its playback position reporting was different. If you want to have better position precision, you used this DSBCAPS_GETCURRENTPOSITION2 flag.

Nowadays, since Windows Vista, the DirectSound is just a software library. It is implemented on top of WASAPI so returned position will always behave in same way. Vista implementation of DirectSound emulates some of old behavior for old applications to work correctly.

It is actually recommended to use DSBCAPS_TRUEPLAYPOSITION flag to report real play position on Vista+. It will prevent DirectSound to do various workarounds/hacks that may be required for old applications.

I see. So what exactly is a emulated Sound Card then? Is that like a VM soundcard or something? Or perhaps a Sound Card which outputs to a file instead of Speakers/Headphones? Also, if Windows uses WASAPI to make DirectSound calls internally, and WASAPI is hardware accelerated, then why can't our DirectSound code be Hardware Accelerated too?

Emulated means that it pretends that there exists sound card - it returns its properties like name, supported sample rates, channels, etc... But in reality all it does it pushes data to WASAPI API which actually deals with real soundcard.

There is not such thing as "hardware accelerated" for WASAPI. All it does it pushes buffers to hardware + retrieves back state. They did not want to manage this kind of code (talking to hardware) in multiple places - WASAPI, XAudio2, WinMM, DirectSound. So they implemented talking to hardware drivers only in one place - WASAPI. Everybody else needs to use WASAPI api for their sound input or output.

This is similar how Windows & C runtime deals with file I/O. Windows supports file I/O only with CreateFile/ReadFile/WriteFile functions. But C runtime calls fopen/fread/fwrite function. And C++ uses std::fstream class. But all that C & C++ functions do, is call CreateFile/ReadFile functions eventually. This is same way how DirectSound works with WASAPI.

DirectSound supported various 3D effects for sounds (like echo, reverb, ..) - those were hardware accelerated in some of cards. Now its not possible to use them through WASAPI. You need to do that in software or use hw manufacturers API. But nowadays computers are so fast, that doing these effects in software is not a big deal. Just like mixing audio.

Ok, I almost completely understand. But, if you don't mind I have one last clarification. Many sources say that there is higher latency in DirectSound; is that because it needs to convert into a form that is compatible with WASAPI?

Yes, that is true. Latency is a bit higher. But it is not about sound sample conversion. You can prepare data for DirectSound in same format that WASAPI expects (for example - 16-bit, 48kHz).

DirectSound adds abstraction layer - it operates in different way how WASAPI does. WASAPI is kind of push-only mode. But in DirectSound you can "lock" the buffer and possibly modify already queued data. DS needs to emulate this API functionality. This means it needs to maybe buffer data a bit more, maybe it needs to delay some of calls. Also the fact that it does this in separate thread does not help - extra synchronization/message passing/etc...

got ya. thanks so much man! i really appreciate your help; it's making following along as a absolute beginner a lot easier.