Hi all,

I'm making my first foray into a sound engine and I'm using SlimDX in order to allow me access to DirectX in C#. I dug around and found a couple of tutorials which got me started and when playing a file from a file, everything is fine. However I also want to look at playing a file from a memory stream (loaded with the contents of a file, stored in a byte array) as I don't want to have to access the hard drive for playing sounds in quick succession.

In doing so I appear to have stumbled across an issue with sound corruption. I'm able to reproduce it 100% of the time on both my home machine and my work machine (both Windows 7) but it only happens with certain files and in a certain order. In this particular case, see the attached file, sounds.zip which contains two files, klaxon2.wav (sounds like the red alert sound from star trek) and warn2.wav (the word warning repeated three times).

The easiest way to describe the issue is to demonstrate the code I'm using to load and play, and the test procedure. I've boiled down the code from my main project to a fairly simple test class:

public class SoundPlayer
{
private XAudio2 m_device = new XAudio2();
private SourceVoice m_sourceVoice = null;

public SoundPlayer()
{
MasteringVoice masteringVoice = new MasteringVoice(m_device);
}

public void Load(string fileName)
{
WaveStream waveStream = new WaveStream(fileName);

AudioBuffer buffer = new AudioBuffer();
buffer.AudioData = waveStream;
buffer.AudioBytes = (int)waveStream.Length;
buffer.Flags = BufferFlags.EndOfStream;

m_sourceVoice = new SourceVoice(m_device, waveStream.Format);
m_sourceVoice.SubmitSourceBuffer(buffer);
}

public void Load2(string fileName)
{
byte[] fileData = File.ReadAllBytes(fileName);
MemoryStream ms = new MemoryStream(fileData);

WaveStream waveStream = new WaveStream(ms);

AudioBuffer buffer = new AudioBuffer();
buffer.AudioData = waveStream;
buffer.AudioBytes = (int)waveStream.Length;
buffer.Flags = BufferFlags.EndOfStream;

m_sourceVoice = new SourceVoice(m_device, waveStream.Format);
m_sourceVoice.SubmitSourceBuffer(buffer);
}

public void Play()
{
Thread t = new Thread(PlayMethod);
t.Start();
}

private void PlayMethod()
{
m_sourceVoice.Start();
while (m_sourceVoice.State.BuffersQueued > 0)
{
Thread.Sleep(10);
}

m_sourceVoice.Dispose();
m_device.Dispose();
}
}

So the idea is load the sound clip into a class and call play. It will play itself in a thread and finish. Please keep in mind that this is a very bare bones example from what's in my main project. Things like proper thread management and object clean-up were not a priority, just reproducing the issue in order to post it here for help (though I'm certainly open to pointers and advice... first timer with sounds after all).

Anyway, stick this class in a project somewhere and, using the attached sounds, use the following code to run it:

SoundPlayer p1 = new SoundPlayer();
SoundPlayer p2 = new SoundPlayer();
SoundPlayer p3 = new SoundPlayer();

p1.Load2(@"..\..\klaxon2.wav");
p2.Load2(@"..\..\klaxon2.wav");
p3.Load2(@"..\..\warn2.wav");

p1.Play();
(NOTE: Replace the path with whatever directory you unzipped the files in.)

What seems to happen is that when p1 is played, it plays a slowed down version of warn2 until warn2 is finished, then plays the rest of klaxon2 until klaxon2 is finished. If I were to use the Load method instead of Load2, it would work fine. If I were to not load two copies of klaxon2, it would work fine. If I were to load two copies of klaxon2 but no warn2, it would work fine. In my tests I've found a few other examples of the problem but for the most part, it's an issue that's hard to reproduce. When you do find a way to reproduce it you can always reproduce it. If that makes any sense... bleh.

As you can see, the way in which I'm loading the stream isn't terribly complex, so I'm not sure what I could be doing wrong. The file data is copied out of the file and put into a new memory stream every time so there shouldn't be any corruption. Can anybody see anything wrong with what I'm doing? Note that I'm certainly not set on this method of playback either... if there was an alternative, I'm interested. I'm also curious as to whether or not it's possible there is an issue with SlimDX, and how one might go about reporting the issue if this is the case.

Again, any help is appreciated as this one has me banging my head on the keyboard.

Thank you!!

Hi Mike,

I appreciate the response, that's actually not a bad idea and pretty easy to implement. That said, it doesn't seem to be the issue. I changed over the code to use a single device and the same issue is present.

I should mention that I'm not locked to SlimDX... if you (or anybody else) has thoughts on alternatives I'm all ears (eyes?). My engine is structured in such a way that I can replace the component that does the actual sound playing fairly easily so I should be able to use any old sound provider. My only requirements are that it can play in a thread and that I can play/stop it (pause is a nice to have but not required). Currently SlimDX using XAudio2 grants me this functionality. I did try SlimDX with DirectSound, but was getting an odd artifact at the end of playback... just a little click sound, so I went with XAudio2.

Here's the updated class for you or any others looking at this thread.

public class SoundPlayer
{
private SourceVoice m_sourceVoice = null;

public SoundPlayer()
{
}

public void Load(XAudio2 device, string fileName)
{
WaveStream waveStream = new WaveStream(fileName);

AudioBuffer buffer = new AudioBuffer();
buffer.AudioData = waveStream;
buffer.AudioBytes = (int)waveStream.Length;
buffer.Flags = BufferFlags.EndOfStream;

m_sourceVoice = new SourceVoice(device, waveStream.Format);
m_sourceVoice.SubmitSourceBuffer(buffer);
}

public void Load2(XAudio2 device, string fileName)
{
byte[] fileData = File.ReadAllBytes(fileName);
MemoryStream ms = new MemoryStream(fileData);

WaveStream waveStream = new WaveStream(ms);

AudioBuffer buffer = new AudioBuffer();
buffer.AudioData = waveStream;
buffer.AudioBytes = (int)waveStream.Length;
buffer.Flags = BufferFlags.EndOfStream;

m_sourceVoice = new SourceVoice(device, waveStream.Format);
m_sourceVoice.SubmitSourceBuffer(buffer);
}

public void Play()
{
Thread t = new Thread(PlayMethod);
t.Start();
}

private void PlayMethod()
{
m_sourceVoice.Start();
while (m_sourceVoice.State.BuffersQueued > 0)
{
Thread.Sleep(10);
}

m_sourceVoice.Dispose();
}
}

Then using it...

public class TestHarness
{
private XAudio2 m_device = new XAudio2();

public TestHarness()
{
MasteringVoice masteringVoice = new MasteringVoice(m_device);
}

public void RunTest()
{
SoundPlayer p1 = new SoundPlayer();
SoundPlayer p2 = new SoundPlayer();
SoundPlayer p3 = new SoundPlayer();

p1.Load2(m_device, @"..\..\klaxon2.wav");
p2.Load2(m_device, @"..\..\klaxon2.wav");
p3.Load2(m_device, @"..\..\warn2.wav");

p1.Play();
//p2.Play();
//p3.Play();
}
}

Don't you need to keeping reference to buffer object? Otherwise .NET garbage collector is free to collect it after your Load method has returned. Even during PlayMethod execution. Maybe that's why the strange behaviour..

Try keeping reference to buffer as member of your SoundPlayer. And call Dispose on it manually to free the data when playback is finished.

That was exactly the problem! I was expecting it to stick around because you hand it off to the source voice, thus I was expecting a reference to be kept alive and the object to not get disposed. Apparently it does, so making the buffer a member variable and disposing it manually appears to have resolved the issue.

Thank you very much!

Well, you see - SlimDX/SharpDX in this matter (who stores references and where) is similar to native DirectX API. IXAudio2SourceVoice doesn't store reference to XAUDIO2_BUFFER. The documentation explicitly states that:

The pBuffer pointer can be reused or freed immediately after calling this method, but the actual audio data referenced by pBuffer must remain valid until the buffer has been fully consumed by XAudio2[/quote]. So you must keep actual audio data (which is stored in AudioBuffer class) if you intend to use it.

Thanks for the clarification and the link. As I mentioned, I'm brand new to this and haven't used native DirectX, so there is a lot of gaps in my knowledge.

Thanks again!