Created SoundEffect plays corruption at end.

I am using :
Sound = new SoundEffect(soundData, 44100, AudioChannels.Stereo);
to create a new sound effect (and due to a large project started before the content pipeline was ready, cannot easily switch to it)

I then create a soundeffectinstance and play it. At the end of the sound (and this is ANY sound) it will not loop and just plays white noise. if the sound is 1 min long, i get 1 min sound, then white noise. this happens with loop on or off.

I’ve tried the latest stable and the latest nightly and same issue (before 3.2 i was using sharpDX directly with no issues - I’ve moved to latest to enable me to go multiplatform)

Does anyone else have this issue? Am I missing something?

How long does the white noise last? Does it depend on the length of the sound effect?

infinitely. Once it starts, it never ends - or at least, it last longer than my ears can handle.

I don’t know if this is implemented on Windows or not but do can you see what the reported length of the sound effect is? I’m wondering if perhaps it’s continuing to try to play beyond what the actual sound effect length is.

it certainly sounds like that. If there is no known issue (im guessing creating a sound via the byte[] overload isnt a common use scenario) ill see if i can get a standalone project to repro and then see if i can fix it myself.

It looks like the Xaudio code for this overload is sent a count based upon the number of bytes in the buffer - when it should be the number of shorts - so the buffer is twice the size of the data it has - which explains the issue perfectly - but im having trouble getting the code to compile (sharpDX version mismatch i think) so i cant confirm yet.

edit: Scratch that, looking at my old xaudio code, it too seems to use byte[].length.

example of issue

this code is as basic as it gets - its a simplification of my code that causes the white noise - in this scenario if just full on crashes (VShost32.exe has stopped working - so no debugging)

I’m going to guess that this is very related to the white noise i get in the larger project.

Sorry for the monologue, but I’ve resolved the issue, and its a monogame bug - but is confusing the hell out of me :frowning:

Line 145 and line 155 of SoundEffect.XAudio.cs sets the loop length. But this is IN SAMPLES ( source ). So the current length (which is in bytes) needs to be divided by 2 to get shorts and it also needs to be divided by the number of channels, so:

LoopLength = loopLength,

becomes

LoopLength = loopLength / (2 *(int)channels)

and then sound is perfect :smiley:

Will this fix be implemented into a fix in a future build? I am currently working with Monogame 3.4.0.456, and I am having the same issue. I load a WAV file via SoundEffect.FromStream, and it plays perfectly until the end, and I then get a loud screeching noise. Then the application crashes.

I encountered this bug today.
It has not been fixed in the latest release of monogame (3.4) as of 9/11/2015.

After a wav file has completed playing, vshost32.exe crashes the application.
This is a very serious issue that needs to be fixed ASAP.
This cripples our ability as developers to create games with sound.

It seems that James Johnston has already presented a solution to this problem, so could we get his code into the official release, so people like me can get back to creating games - with sound?

Thanks

I just checked the latest unstable build (3.5.0.574 updated on 9/04/2015) for this issue.

Wav files loaded using SoundEffect.FromStream() throw no error.
But no sound occurs when .Play() is called.

I wish I knew how to build monogame’s source, I’d implement James’ solution and get back to developing. If anyone has a guide on how to build monogame’s source to an installer, drop a link here, please. Google has failed me.

Thanks.

I didn’t see an issue listed with the current open issues that matched exactly to this issue, so I have submitted this an an issue and referred back to this thread.

Many thanks to MichaelDePiazzi for pointing out the already existing issue (PR #4049). It appears there is a fix for it in 3.5.0.450, though there is no official MonoGame release beyond the current 3.4. Would love to see an official release with the many fixes that have been made in the near future.

We do plan to get a new release out soon. Tom has been hammered by current projects at his studio which has been taking all his time recently.

1 Like