Breaking Changes in XNA 3.1 SoundEffect

I hate breaking changes. They are like getting into your car and finding that the steering wheel is now the gear lever, and the seats are facing the other way.

Generally speaking the people who make the software try to avoid them too, which is as it should be. But every now and then they make the judgement call that somebody else’s pain is worth their gain, and so they go and move the universe around a bit.

They have done it with the move to XNA 3.1 from XNA 3.0. XNA 3.0 introduced a new SoundEffect type which made it much easier to make sound. Unfortunately, in its original incarnation this type also made it easy to inadvertently make sound that stole all the sound channels by mistake, and so they have fixed this in version 3.1.

Essentially, in XNA 3.0 the SoundEffect.Play() method used to return a reference to a SoundEffectInstance object, that you could then tweak to change some of the properties of the playing sound. This was kind of neat, except that if you ignored the return from Play it meant that the SoundEffectInstance that was created ended up being left hanging around, probably hogging a sound channel, until the garbage man got around to killing it off. If your game was well designed and looked after memory properly this may not happen of course, and so you would run out of sound channels for no good reason.

In XNA 3.1 the same Play method returns something different. It just sends back a boolean value that indicates that the sound is playing correctly. To get hold of a SoundEffectInstace you have to call the aptly named CreateInstance method on your SoundEffect. All very sensible, and much less likely to hog all the sound channels.

However, if you have just written a book which carefully describes the way that XNA 3.0 works in this respect (just like I have) then you are left wondering why they didn’t add an extra method (perhaps called QuickPlay or something) and leave the old Play intact…

Oh well.

Comments

[Laura compañías aseguradoras]

Really strange, I have the same opinion. They should have leave the old Play intact

[Rob]

I think the reason why they changed it is that it was such a dangerous thing to leave in place that they really wanted to stop having to return SoundEffectInstance values for a simple Play, and force people to do things a different way.

And since around 90% of the calls to Play will ignore what it returns, most code will migrate fine anyway and end up working better. In other words, the change will fix lots of broken programs without the programmers having to do anything...

[Rob]

Hmmm. If they had been *really* clever they would have made the SoundEffectInstance that you get back from Play a weakly linked handle that would do some clever location of the actual sound it was bound to, so that unless you asked it to give you control over the playing sound it pretty much did nothing. Bit like an Extended Weak reference in the Micro Framework.

As soon as you called one of the methods, or used one of the properties on your SoundEffectInstance it could have gone off and found the sound that was supposed to be bound to and done something with it, or thrown an exception if the sound was no longer available.