duplicate sound buffers and buffer contents

[Ian Hawley]

I create an IDirectSoundBuffer and use it to hold the wave data, but never
actually play that buffer. When I wish to play the sound I duplicate the
buffer each time I play the sound, releasing buffers I have duplicated as
and when they are stop or come to end.

This works fine.

Because there is no interface to modify the looping points of an
IDirectSoundBuffer (Doh!!) I'm having to do some streaming into my buffer
to get around the problem. However, as soon as I have done this I end up
modifying the original buffer! Is this to be expected or is it because the
first buffer isn't being played and/or has no resources assigned to it per
se ?

I was trying to avoid having to create the directx interfaces from scratch
at the point of playing the wave, believing this would lead to less latency,
but perhaps I should hold the wave as it's bytes and format and create the
interfaces on the fly?

Any help with this would be much appreciated!

Cheers
Ian

---
This email has been checked for viruses
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/2002

[bob]

Hi Ian

This is very interesting - I am researching similar requirements at the
moment.

I have thought of 3 approaches here:

1. Keep your wave data in normal RAM (or on HD) & stream it into a
DirectSound buffer manually, doing your own loop point processing.

2. Keep your wave data in normal RAM (or on HD) & run up a new
DirectSound secondary buffer whenever you need to change the inpoints
with that piece of data in it. Run down the buffers when you are done
with them.

3. Use DLS, which gives you access to hardware buffers with real looping
IO points.

========================

1. Is very tried & tested, but involves a lot of programming work,
introduces buffering latency & loads up the CPU & windows.

2. This is an idea I've had that I haven't tested yet, but it may be
very attractive if it works. Once the buffer is playing each time there
should be very low latency & cpu load. programming wise it sounds good too.

3. I haven't tested this either yet - it sounds like it might be hard
programming wise, and we might have to stop the buffer to change the IO
points, but all it might be the really proper way of doing this. More
research needed here for me anyway.

=========================

Any news on this subject greatly appreciated

I will try to post more later when I know more.

Russell

[Ian Hawley]

Hi Bob,

Well I notice (now, wish I had seen it earlier!) that content of duplicate
buffers is not guarnteed to be the same. Which means the content could be
the same, explaining why when changing a duplicate I change the original.

Because I am using an IDirectSoundBuffer as a holding area for the wave
data, it's probably the case that - this is of course pure speculation - the
interface isn't attached to any hardware at all (because I am using defered
loc flag) and so it is just copying the data into the software/hardware
buffer at the point it is actually played. In essence I need this to happen
each time the wave is played, so I might as well just store the sample bytes
and dump them into the buffer as the wave is played. Yes there might be
some latency with this, but I don't think it will be noticeable provided the
sound card is *not* on the ISA bus, but on the PCI or faster.

I'm bus re-writing (again) the inside of my import and play methods. I'm
precalculating as much of the information as possible.

I can of course after I've got around this problem, include the dummy
IDirectSoundBuffer interface(s) back into the new system, allowing me to
make use of those when I am playing back sounds that don't have a sustain
loop. As it is only these sounds that are causing me any greif, even more,
it's only when I play a sound *with* a sustain loop looping; so it must loop
the sustain. Otherwise I can just play it "in the normal" way.

I'll let you know what I discover. I'm looking for the most optimal method.
I want as little hit as possible here so I'll be aiming at this hybrid
system.

I guess this is sort of a mix of your 1 & 2 methods. I'm not going to
entertain any solution based in DirectMusic as I've already had to re-write
90% of the inside of our audio engine due to problems with pitch-shifting
waves and performance spikes (30% CPU usage!). If the damn interface
*simply* incorporated a much needed IDirectSoundBuffer::SetLoopStart(DWORD
dwStart); type function I wouldn't have to do *any* of this faffing about!

I'll let you know how successful this is.
Cheers
Ian

"bob" <bobl...@brightonart.org> wrote in message
news:3CF761E8...@brightonart.org...

[Alan Ludwig [MS]]

Duplicate sound buffer doesn't create a seperate copy of data for the new
buffer. Duplicate sound buffer is used to create a new hardware voice that
points at the SAME data. This is to facilitiate playing repetitive sounds
without having to have multiple copies of the same data.

Think about explosions in a game. You are potentially going to hear that
explosion several times a second, with perhaps as many as four or five of
the explosions playing at the same time. Duplicate buffer allows you to be
playing all four or five explosions at one time, at different points in the
.wav but only storing the data one time. Very efficient!

If you want complete and seperate copies of the data, then just create a new
buffer and copy the data into it.

Regards,

--
Alan Ludwig
Software Design Engineer -- Windows AV Platform -- Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Zlamal]

...THEN WHY IS THIS METHOD DEPRECATED?!?!

This seems like such an excellent method to make multple
sounds of the same source, saving lots of memory.

The bottom statement in this post is taken DIRECTLY from
the dx8.1 documentation... Notice how this documentation
completely contradicts itself in the first two lines???

The purpose of DuplicateSoundBuffer should be to infact
SAVE memory and NOT make memory copies of the data..

What am I missing here? Clearly there is something wrong
somwehere... Is it me? Also I am observing that in other
sections in the.

MSDN Home > MSDN Library > DirectX > DirectX 8.1 (C++) >
DirectX Audio > DirectSound C/C++ Reference > DirectSound
Interfaces > IDirectSound8
*****************************
IDirectSound8::DuplicateSoundBuffer
The DuplicateSoundBuffer method creates a new secondary
buffer that duplicates or shares the original buffer's
memory.

This method is deprecated. Duplicate buffers do not share
memory on most systems, and effects set on the original
buffer are not set on the duplicate.
*****************************

Please help, this is very confusing, particularly because
when I search for DuplicateSoundBuffer in MSDN, several
references come up, some pages describing the above, and
some describe the intended behaviour of this method (the
non-deprecated behavior).

Mark!

[James Dooley (MS)]

Old ISA soundcards had memory on the soundcard that could only be accessed
across the slow ISA bus, in which case it made sense for
DuplicateSoundBuffer to actually re-use the memory on the soundcard.
However, all modern soundcards use the main system memory for playback, and
DuplicateSoundBuffer will just copy the sound data to another memory
location and return an interface that wraps that new memory buffer.
I'm not a DSound expert, but I think that the reason DuplicateSoundBuffer is
depreciated is because is no longer "shares" the data between two DSound
buffers. Since you can do the same thing by creating two DirectSound
buffers and copying the same data into each, the method's not very useful
anymore. It also causes developers to mistakenly think that using it will
actually save them memory by sharing the sound data, or that settings (such
as effects) on one buffer will be propagated to the duplicate buffer.
I agree that it makes much more sense to separate the sound data away from
the control information (so that you can actually share the sound data,
instead of having to make many copies of it), but that's just not how the
DSound API was designed to work.

-james

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"Mark Zlamal" <mzl...@espial.com> wrote in message
news:1165c01c21eba$72f9f790$36ef2ecf@tkmsftngxa12...

[Ian Hawley]

In my experience the method does not always create a duplicate on modern
soundcards I think that whether you get a duplicate buffer or not is down
to the hardware and the driver, so it can change across machines even.

One reason I initially wanted to use DuplicateSoundBuffer, was that I had
assumed this would be quicker to use than manually setting up a new buffer
and copying in the data. Additionally, this means you must have a copy of
the data as well. However, from what you are saying it seems there is
little benefit in doing this if any.

Cheers
Ian

"James Dooley (MS)" <jdo...@online.microsoft.com> wrote in message
news:#iFwy9vHCHA.2212@tkmsftngp12...

[Ultra_Newbie]

A look at the following may be helpful:
http://msdn.microsoft.com/directx
Click Technical Articles, DirectX Audio, Sound cards
Voice Managment and driver models

Basically it says (in my mind)
If you have a real PCI sound card (as opposed to just a DAC with
software drivers.)
AND Win98SE/Win2K/WinXP
AND WMD drivers
Then everything is mixed in software with very low latency and no real
limit on the size or amount of sound buffers up to the amount of physical
RAM in the PC.

"Ian Hawley" <i...@NOSPAMawesome.uk.com> wrote in message
news:#vOw7fNICHA.2696@tkmsftngp12...

[Mark Zlamal]

I don't suppose that there will be a method in the future
to "duplicate using same memory" (DX9?) :) :) :)

Also, if the Buffers use system memory (modern cards),
then isn't Lock() and Unlock() not really relevant, since
the sound data is not copied to different system areas?

If only I could somehow get 2 or more buffers locking a
pointer to the SAME memory area that would be sweet!

My 3D graphics (and 3D Sound) application:
I have 25 fighters, each containing 2 blasters on the wing
tips. Each blaster has an associated Sound wrapper which
contaings a directsound object. If my blaster sound
sample is 50 kBytes, then I am actually occupying
50KBytes*2*25 = 2.5 Megs of sound (the same sample copied
over and over)... It's too bad that I can't shrink my
memory usage to the expected 50 Kbytes using
duplicateSoundBoffer...

Is there any suggestion to make this above programming
sample more memory efficient?

Thanks in advance,

Mark!

[Alan Ludwig [MS]]

Go ahead and use DuplicateSoundBuffer. When it can, it uses the same
memory, but that is not always possible.

As for having 2.5mb of memory for your 50 (2*25) sound buffers, you are may
be taking the wrong approach here. You probably aren't going to have that
many hardware buffers, and you want to play as many sounds in hardware as
you can.

Consider using some kind of "pool" approach to your laser cannon sounds.
Decide on a meaningful number of "simultanous" blaster sounds. I'd suggest
that your ear probably can't locate 50 different blasters all sounding at
the same time anyway. After just a few it simply sounds like they are
coming from everywhere. So, don't bother sounding all of them, sound only
the closest 3 or 4 (that are currently firing). Each time a new "blast"
needs to be voiced, check to see if it is closer than the most distant
blasts that is currently sounding. If it is, then steal that voice, and
start a new blast sound. Louder sounds in the foreground mask quiter sounds
in the background anyway, so this behaviour sounds fairly natural.

It is easy to end up with hundreds of sound emitting objects in your game
universe, and you probably aren't going to have the sound hardware to give
all of them a voice all the time. You need some kind of "voice-management"
scheme so that the "most important" sounds get a voice, and the rest don't.

Hope this helps,

--
Alan Ludwig
Software Design Engineer -- Windows AV Platform -- Microsoft

This posting is provided "AS IS" with no warranties, and confers no rights.

[Ian Hawley]

With sounds, models and other static resources (i.e. that are not modifed)
it is wise to have a resource manager. In such a situation you ask the
resource manager for the sound effect. i.e.

cMySoundRef *pSoundRef = GetSound(uMySoundRefID);

And then when you have done with the sound, you perform something similar
such as:

ReleaseSound(pSoundRef);

The resource manager handles the reference counting, loadind and unloading
of the sound. Your play function should create a new IDirectSoundBuffer in
whatever way it needs to.

As suggested, duplicate RAM will be used where possible and it's unlikely
you'll have 50 laser shots firing at the same time. In addition, you should
place a limit on the sound effect to say how many concurrent times it can
play.

Hope that info helps
Ian

"Alan Ludwig [MS]" <ala...@online.microsoft.com> wrote in message
news:Xns923F9DF6...@207.46.239.39...

---
This email has been checked for viruses
Checked by AVG anti-virus system (http://www.grisoft.com).

Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002