Many are still looking for a solution for the Silverlight sound problem. What are the problems and what is the solution?

People who tried to create a casual game in Silverlight, encountered problems when they added sound effects to the game. The time between starting a sound effect and actually hearing it, is unacceptably long. This is called “audio latency”.

Short effects, typically less than a second, sound good the first time, while they sound bad the second time when they are played. The source of this problem is not clear, however long sounds don’t have this problem. This is called the “short sound problem”.

Also, it is very hard in Silverlight to play music in an idle loop. An idle loop with the out-of-the-box MediaElement, plays a silence every time the music is repeated. The silence at the beginning is actually caused by the same audio latency described above.

The above problems exist in Silverlight 4 and lower versions.

The audio gap
The music compression format MP3, is standard encoded with a silence at the beginning – the audio gap. This is because the decompression code needs some time to get ready, like an engine which needs time to get started. Tools like WinLame may encode an MP3 without an audio gap at the beginning, but this does no good to Silverlight’s decompression code. An MP3 created with WinLame will sound bad.

The audio buffer
Silverlight uses an audio buffer internally, which needs to be filled with audio data before any sound is played. The size of the audio buffer is measured in time, and it costs exactly that time to fill the audio buffer, before any sound is heard.

Reducing audio latency
The audio latency is caused by the audio gap from the music format and because of the audio buffer. So if we want to decrease the time between calling the Play function and actually hearing sound, we need to handle both the audio gap and audio buffer. Now obviously, a latency of 0.0 is impossible, otherwise Microsoft would have provided this with Silverlight.

The solution: VorbisPlayer
The solution is to choose for an audio format which is gapless. Second, the default length of the audio buffer must be decreased. And for a seamless idle loop, we must stream the next music part into the audio buffer, right after the previous music part has finished.

Ogg Vorbis is a music format which can be encoded without audio gap, however it is not supported by Silverlight. However, Silverlight does allow developers to implement their own audio decoder.

The VorbisPlayer provides exactly the solutions described above. More important, the VorbisPlayer is easy to use, for not so technical people.

The VorbisPlayer allows low latency for sound effects, much lower than Silverlight provides out of the box. Because of the used technique, the short sound problem is also solved. Also, the VorbisPlayer has an easy function to invoke a playlist of music, which will be played seamless without gaps in between.

The Silverlight VorbisPlayer can be found on Codeplex: http://vorbisplayer.codeplex.com/

Great developments on the VorbisPlayer. To reduce the download time of Slengo, the bitrate of all sound in the game was reduced from 44.1Khz to 16Kh. Although the quality of the sound is lower, it still sounds quite good. 1.87Mb of data was reduced to 0.99Mb.

Another advantage is that the VorbisPlayer uses less CPU at this bitrate, and performs much better. On high-end machines, people did not have much problems with performance, however on lower end machines the sound could stutter. With a lower bitrate, this problem solved for low-end machines. The VorbisPlayer was modified to allow for lower bitrates.

A new release of the VorbisPlayer has been uploaded on CodePlex:

For most of my games, I have created a level editor. I usually create a Silverlight page, at the top I edit the levels and at the bottom I embed the game to test the level. This way it’s very easy to test your game for bugs, and to test whether a level is actually playable. How a level editor works, depends on the game you are creating. For “Mineral”, I created a different level editor than I did for “Avios”. The Avios editor clearly is much more complex than the Mineral editor. However, some things are basically the same.
I’m creating a new game, let’s take the reader along the path. The game I’m creating is called “Slengo”, highly inspired by the game “Pengo”. So the basics of a level is clear, it is a two-dimensional grid, like Mineral, and everything happens in there.

After creating a solution and a Silverlight application (Slengo.App), with ASP.Net Web Application Project (Slengo.Web), we can add our own things. Highly inspired by the SOA-model programming, I usually split things up top-down. The Silverlight application itself does not contain much code, everything is done in the Silverlight libraries.

The way of creating a level editor, is the same way I did for my first game “Tilez”. The editor is a Silverlight page, which reads all levels from the webserver when started. If I press the button “save” in the editor, I want to save the level I am currently editing. When I close the application and start it tomorrow, I want to see all levels I’ve saved before. Those are my basic requirements.

The image shows the basic setup. In the project “Slengo.Visuals”, I will put all my sprites, all my basic visual things. Currently the project has one usercontrol, “IceCubeBlue”. This control displays an IceCube, which is a level building block. Note the name of this usercontrol, I will create a “IceCubeRed” in future, or another item if I want to. An icecube acts like a wall, and where there is no icecube, there is a path for player and enemies to walk.

The project “Slengo.Web” has a webservice called “Levels.svc”. You create this by selecting the project, Add new item and under the Silverlight templates, you’ll find the Silverlight-enabled WCF service. Currently this service is empty.

Next is to focus on your level data-model. The data-model is created on the server, not in the Silverlight application! There are two reasons for this:

First, if you want to store level data, you need to serialize the level data, for example to XML. Silverlight does not have full capabilities to serialize or deserialze data, but your server does. If you are serializing the data on your server, the data-model needs to be known on the server anyhow.

Second, if you want to send level data from your Silverlight application to the server via Soap (to your WCF service), then you are limited to the data-types supported by Soap. If you do not know all the types which are and which are not supported by Soap - like me - then you will discover your own errors very quickly if you do something wrong. A good example of a data-type which is not supported by Soap is the two-dimensional array.

The good thing is, that if you create the level data-model on your server, this model will be available in your Silverlight application later.