New Sample code and new SoundBuffer function request

[GoogleCodeExporter]

There aren't many samples for DirectSound in SlimDX and I thought you might
want to copy one of mine and put it in the SlimDX SDK.  I've created a
program at

https://crmplayer.svn.sourceforge.net/svnroot/crmplayer/CmPlayer08

in branches/PlayDirectSound which uses FFMpeg and SlimDX to decode and play
mp3 files.  There's a readme.txt with instructions.

As part of my development I'd like to request a new function: an overload
of SoundBuffer.Write with 2 new parameters "int dataOffset, int dataLength"
which would allow sections of buffers to be written to the DirectSound
buffer.  If the team implemented this function they could test it with my
sample player by breaking up the current Write into multiple sections.

Original issue reported on code.google.com by CRMeadow...@gmail.com on 12 Jan 2009 at 6:11

[GoogleCodeExporter]

This is an enhancement request not a defect, sorry.  I don't see how to change 
it.

Original comment by CRMeadow...@gmail.com on 12 Jan 2009 at 6:12

[GoogleCodeExporter]

Sure.

Original comment by Mike.Popoloski on 12 Jan 2009 at 2:02

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Whilst you're playing with SoundBuffer::Write, and overload to support writing 
short
[]s would be useful (instead of just byte[]s).

In IRC, jpetrie mentioned:

"So SoundBuffer is not of type DataStream? That's odd."
"I wonder why."
"At first glance it seems like it might be reasonable for there to be a short[] 
overload then."
"It looks like offset is passed to the lock call."
"And the lock gives Write a DataStream, on which he could call WriteRange()."

Not sure if this should be a separate issue, though, but seems related.

Original comment by benry...@benryves.com on 13 Jan 2009 at 6:08

[GoogleCodeExporter]

I've fixed the SoundBuffer stuff. I'll leave this open until I integrate the 
sample.

Original comment by Mike.Popoloski on 23 Jan 2009 at 11:12

[GoogleCodeExporter]

Upon further reflection, I don't think it's a good idea to include that sample, 
since
it relies on a completely separate library. However, it's still a good 
candidate to
show off the library working in tandem with another, so I'm going to add a link 
to it
to issue 345, which is where we are holding on to community provided content. 
Once
the new website is up, you'll have a place to submit it.

Original comment by Mike.Popoloski on 24 Jan 2009 at 4:00

• Changed state: Fixed

[GoogleCodeExporter]

I'm not happy with the fix.  If I pass count=0 to SoundBuffer::Write the call to
Utilities::CheckArrayBounds will change count so that the entire data buffer 
(from
startIndex) is written whatever its size.  Imagine trying to debug why your 
game has
choppy sound every once in a while just because some audio decoder tells you 
there's
a 0 length buffer every once in a while and SlimDX decides to play whatever's 
in your
byte array?

Utilities::CheckArrayBounds seems like the troublesome function since it does 2 
jobs
(checking array bounds and sometimes changing the count value from 0 to the 
maximum
allowed).  It fails the Single Responsibility Principle.

I'd like SoundBuffer::Write to just return immediately if count==0.

Original comment by CRMeadow...@gmail.com on 25 Jan 2009 at 6:48

[GoogleCodeExporter]

0 meaning "the entire buffer" is idiomatic throughout SlimDX because it's 
idiomatic throughout most of the 
native API as well, I'm not comfortable making such a change just to the sound 
buffer classes, and it would be 
troublesome to make certain other scenarios possible using the proposed 
0-size-means-do-nothing change. 
It's easy enough to check for a zero size before you call the function, but 
it's hard to pass the correct size when 
you have an interface that doesn't trivially expose its size.

Original comment by josh.petrie on 25 Jan 2009 at 5:35

[GoogleCodeExporter]

Well, in C# I'd use a nullable int for this, or better yet overload the 
functions to
provide a method without a length parameter so the implied length is made 
explicit,
but if this is a matter of keeping the design consistent within the project 
that's
important too.

Original comment by CRMeadow...@gmail.com on 26 Jan 2009 at 6:36

[GoogleCodeExporter]

I would have to agree with CRMeadowcroft, api should have overload with no 
lenght
parameter.

- data, a happy sdx user

Original comment by lemons...@gmail.com on 16 Apr 2009 at 12:42