Music Stops After a While

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!

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

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.

Cheers.

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.

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.

[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.

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.

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.

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.

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

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 ...

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.

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)

http://www.ogre3d.org/phpBB2addons/view ... 4&start=15


Cheers

Andy

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

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.

Cheers
Andy

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.

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.

Guess I spoke too soon...

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!

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.

Why?

Did you build it with threading support?

I do not add additional code for threading support.

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

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
# define OGREAL_THREADED 0
#endif and you would need to change it to:#ifndef OGREAL_THREADED
# define OGREAL_THREADED 1
#endifOnce you do that it should build without trouble.

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

Ok. I try to download latest boost..

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

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.

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.