Jump to content
  • Advertisement
Sign in to follow this  

DirectSound - hardware, software, primary and secondary buffers

This topic is 2858 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have read a lot of info about DirectSound buffers but some articles are outdated and MSDN is tricky to navigate to get the overall structure clean in my head.

Let's start with Windows XP and DirectX 9.

Some old articles confused me saying that only static buffers are in hardware, but MSDN says: "On PCI cards, static buffers and streaming buffers are effectively the same."

So, I assume, I can get streaming buffer in HW without problems, great.

According to the MSDN, I should not mess with primary buffer, it is small and hard to manage. So I'll use a secondary streaming buffer and pass the flag to put in in hardware, if possible (it is also the default behavior of DS).

But what about primary buffer? As far as I understand, primary buffer is where all the secondary buffers are mixed (all - what? all DirectSOund secondary buffers, all of my application sec.buffers or all of Windows secondary buffers?)

But if I have a secondary buffer in hardware, how the mixing will be done and who will do it - the audio card (I would want that), the DirectSound or the KMixer? And if secondary buffer is in hardware, then the primary buffer also is in HW?

If I have an integrated audio chip (Realtek, CMedia), does that mean that even "hardware mixing" is done on the computer CPU?
And are hardware buffers available on those integrated chips?

I have read about that primary buffer audio format should match my secondary buffer format to minimize mixing, but I am not sure what will happen if my secondary buffer is in hardware.
If I want to get maximum out of my sound card and have minimal latency with one secondary streaming buffer in hardware, how do I avoid some mixing from occurring (to skip KMixer)?

What about capture buffer, how to get it also to be efficient and skip mixing/resampling?

Now let's look at Windows Vista/7

DirectSound does not have access to hardware buffers at all. So what should I use there - XAudio2 or WASAPI to get the same DirectSound-like straight-forward implementation to efficiently access hardware buffer of my sound card?

What I am trying to achieve is some simple C++ audio wrapper dll which would choose the best technology based on where I install the application - on XP or Vista/7. This dll is meant for use in a scientific audio application where latency is really important.

And what almost kills my idea is also the following sentence from MSDN: "Hardware buffers are not supported in 64-bit operating systems."
Completely and at all no way to get hardware acceleration on 64 bit Windows?
Not on XP, not on Vista, not on Win 7 ?

Some implementation questions

I have not found what is the optimal way to manage playback buffer. I know that I need to be able to fill data fast enough to avoiddropouts and I should never write on the sector where play/write cursors are -dropouts guaranteed.

But I have no idea in how many parts it is advisable todivide the buffer. If I have1 sec buffer, is it OK to use only two parts 0.5sec each? Or is it better to use four 0.5 sec parts and 2 sec buffer? If I letuser adjust latency, what should I allow to adjust - total length of the bufferor number of sectors in the buffer?

Microsoft prefers using buffer notifications, but there aresome people who say - notifications get screwed up if many applications areusing them simultaneously. So the polling is a better choice?

And finally - the play/write cursors on the secondary buffer. If the buffer is software buffer, then what does play cursor show - the sample which is being played or the sample which is being sent to the KMixer (which will introduce about 30ms delay, according to MSDN)?

I know, too many questions in one post, but I'll be glad if you could help clear things up.

P.S. Merry Christmas!

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!