Music Stops After a While


30-04-2007 11:42:57

Hi. First, thanks for such great wrapper, it is amazing.

I am having the same problem other users have. The music starts playing then stops after a second or so.

To avoid this problem i start the music after everything has been loaded and the scene has started.

I have discovered other way of seeing this problem. Just start the game in windowed mode and move the window for a while, or just lose the focus of the windows. Then the music stops.

Perhaps this could help you to fix this problem.
I am using the latest version for Eihort from the cvs.

Thanks again!


30-04-2007 18:00:37

maybe you have attached your sound to a sceneNode that moves away from the listener very fast?
for example, if you have it attached to a node thats uses physics, and this physics object "falls" down far away into the dark which means that you can't here it because its too far away from your listener.

also maybe try using "createSoundStream(...)" instead of "createSound(...)".
i did that because my oggs dont play by using "createSound(...)" but they do by using "createSoundStream(...)", although they are very small ("createSoundStream(...)" for long sounds, normal "createSound(...)" for short sounds like "ouch" i thought).

or maybe just check the format of your soundfile (what you surely already have done right? ;) )

i hope i could help you


01-05-2007 00:52:45

Thanks for your answer, very much appreciated.

The problem i comment is the same other people are having. Look in a post below about ogg streaming.

The problem occurs when something takes too much time to process (about 2 secs), then the music stops.

I use createsoundstream, and i don't attach to any scene node.

In fact, if i try to destroy the sound when this happens, i get an error.

This is easily to reproduce if you execute in windowed mode, then click on the window (just like if you wanted to move it) and hold the mouse clicked for a while. Suddenly the music stops.

This doesn't happen with WAV's.



19-05-2007 02:50:30

it doesn´t have to do with the file format (ogg, wav) of the sound, its about the difference between static and streamed sounds. A streamed sound (useful where loading time has to be zero to short and/or soundfile size is to big to hold the entire data in memory) has to be updated from time to time, to fill a short buffer with new sound data from file, while another short buffer is playing the last data filled, called double buffering. since OgreAL perfomes this update in the frame loop of the normal main thread, the sound is interrupted when the frameloop is not running fast enough. The only good solution to this would be a design change in OgreAL, where streamed sounds are updated from a second independend thread, but this needs multithreaded access to the ogre resource system, that is (as far as i know) experimental or not completely implemented. I have implemented streamed sounds using ogre resource system a year ago (Ogre 1.2), while using my own locks and mutexes. May be there is better support in the recent versions, that make multithreaded resource access a bit more easier, general and less hacky.


20-05-2007 12:44:43

This behavior can be explained by the fact that when a source reach the end of the last buffer in the queue, it goes into AL_STOPPED state unless looping is enabled.

There are 2 solutions : make the stream updater in another thread, or increase the size of the buffers used in the double buffering system. Increasing the size of the buffers may produce CPU pikes unless the filling of the buffer is done in several steps, which probably only work with a threaded system.

I never used OgreAL so I don't know how this can be done.


05-06-2007 07:11:18

[Thanks to everyone posting on this topic.]

We have a production system that uses OgreAL and is suffering from this issue. Are there any stop-gap measures (short of switching to FMOD for which we can't afford the commercial license fee at the moment)? Our sound file is only 5Mb so it will easily fit into memory alongside the rest of the program. Is there a way of forcing the stream to load into a single large buffer? Any help is much appreciated.


05-06-2007 16:57:32

I have just moved and am getting everything set up again. I am going to look into this as soon as I can, I truly apologize for the delay! I am going out and buying a desk this weekend so I will be able to get to it next week.


05-06-2007 20:34:32

I have just moved and am getting everything set up again. I am going to look into this as soon as I can, I truly apologize for the delay!

No problem, CaseyB, OgreAL is a voluntarily effort after all. And a much appreciated one at that!

We do need a rock-solid sound solution by the end of the month. If there's anything we can do to spur this along (financially or otherwise), please let me know. And if you don't think the problem can be fixed in the next few weeks, could you tell us? In this case, we'll have a few weeks to arrange a temporary alternative.


05-06-2007 21:06:32

If there's anything we can do to spur this along (financially or otherwise), please let me know.I really appreciate that, money's not the problem, but if you could squeeze a few more hours in the day that'd be GREAT! I can't guarentee that the problem will be fixed in the next few wekks, but I will track it down the problem and if it's on my end I'll fix it and if it's an OpenAL issue I'll post a message on the forum. So if it's an OgreAL issue it will be fixed, if not I'll let the right people know.


20-06-2007 06:50:59

Hi CaseyB, any word on this loss of sound issue?


05-08-2007 03:19:54

Just checking back to see if any progress has been made on this issue? We have an Ogre project coming up in the fall that will require robust sound. We'd like to use OgreAL ...


04-09-2007 22:30:29

I'm also thinking about using OgreAL in a multithreaded program to make the sound more robust. Has anyone successfully done this yet? Just curious.


05-09-2007 06:43:49

Did you apply the patch I posted as it will certainly fix the playing of ogg files (and I don't really see any reason to use ogg streams unless your ogg file is 10's of megs in size) ... 4&start=15




06-09-2007 21:16:28

Andy, if I understand correctly, your patch solves the speed issue and not the sound-stopping problem, correct?


07-09-2007 00:03:11

That is true, however have you tried the patch and does it solve the stopping problem?

I ask as setting the speed incorrectly could have all sorts of knock-on effects.



07-09-2007 00:10:48

I included this patch into the latest in SVN, I also beefed up the ogg loading so that should go better for everyone. I am going to be making some changes to the API. They should not be breaking changes, but I will let everyone know if they are. Thanks for the heads up with this problem.


07-09-2007 01:07:38

Sweet! I was starting to think OgreAL was dead.. lol. Not that I have gotten to the point of using it a whole lot, (unfortunately) but I always like to poke around and see if anything is happening. :)


13-09-2007 00:39:23

Guess I spoke too soon... :P


13-09-2007 04:00:58

hehe, you didn't speak too soo, things have just been CRAZY busy around here. I am working now on removing the ALUT dependency, it's pretty slow going to ensure that it's robust enough but I have a couple of good examples that I am working from so it should be good eventually. Thanks for keeping up with it all! :D


09-01-2008 00:36:07

this error does not fixed?

After 1-2 music in application is stoped.
Also I try next:
I start application in window mode, after I click on this window on taskbar and background music is stoped.



09-01-2008 02:51:12

Did you build it with threading support?


09-01-2008 07:55:36

I do not add additional code for threading support.

Or you may in view settings Runtime Library = Multi-threaded DLL


09-01-2008 12:22:10

The problem with that was that the update for the audio buffers was tied to the frame rate, so if the frame rate dropped, the music would cut out. They fix I put in for that was to use boost to spin off a separate thread that would update the sounds independent of frame rate. I didn't want to force boost to be a dependency for OgreAL so I built it in conditionally. To activate threading the first thing you'll need to do is download and install boost::thread, then you need to change a line in OgreALPrereqs.h. It looks like this by default:#ifndef OGREAL_THREADED
and you would need to change it to:#ifndef OGREAL_THREADED
Once you do that it should build without trouble.


09-01-2008 12:46:54

But this is need boot library...
Why you use standart API?

Ok. I try to download latest boost..


09-01-2008 22:14:14

Because boost is the easiest and cleanest way to get cross platform threading.


09-01-2008 22:22:51

This is probably a dumb question, but is OgreAL using multi-threaded and Ogre using single-threaded compatible? I believe the Ogre SDK's are built to be single threaded use of Ogre, right?

I plan on downloading OgreAL from SVN tonight, is it in a useable state? :)

I should probably make my own Ogre SDK for the other dev's on my team using multi threaded support, as well as OgreAL.


09-01-2008 23:27:06

is OgreAL using multi-threaded and Ogre using single-threaded compatible?
Yes, it's compatable. The Ogre stuff runs all in the same thread, the other thread just updated OpenAL stuff. Threading is turned off by default in OgreAL, so it's something you have to want and activate, otherwise it will behave exactly as before.

I plan on downloading OgreAL from SVN tonight, is it in a useable state? :)
Yup! Have at it! ;)

I should probably make my own Ogre SDK for the other dev's on my team using multi threaded support, as well as OgreAL.
I like the idea of building from source. It just feels like I have more control. But if you are going to be doing anything very complicated you might want to build in the Threading support in Ogre.