[Solved]Hanging Pauses when creating a Sound

right now i getting a little hang when creating a new sound. It behaves the same using streamed or static sounds. I traced it down to this method.

ov_open_callbacks(...)

http://www.xiph.org/vorbis/doc/vorbisfi ... backs.html

check the notes on the link, there is an interessting part about Threading.

Do you get a hang when not using multi-threading also?

jap i am using the multithreading build

I'm guessing you'll get the same problem even in the non multi-threaded version also, I'm not sure of a way around it really, aside from putting that single call in its own thread.

I think what I could do is remove the seek/tell functions from static sounds callbacks, once loaded they aren't accessed again so seeking isn't necessary, that would speed up those...

you could use the streaming thread to call all methods that loads the file from the IO. Like you are already doing in the OggSoundstream _stream(), and use the ov_test_callbacks in the create method to get all information out of the Vorbis file. Because this function does not block the thread.

I've removed seek/tell callbacks from static ogg sounds for now, updated SVN. I'll note the issue for streaming sounds and see how it progresses.

hmm it makes no difference because the ov_open_callbacks(...) call itself blocks the thread to long. The best would be to test the og with the test callback and then use the thread in threaded version to open the callback and fill in the buffer.

Maybe I'm misunderstanding your problem then, as I understand it removing the seek/tell functions will definitely make a difference to any ogg file opened with ov_open_callbacks() so that should now be improved for static sounds.

I was assuming you were trying to create and play a sound instantly but were suffering from delays, is this not the case?

Sorry for not explaining it more precisely.
The case is that, when I create a sound with the manager, I get a hang in the framerate because the ov_open call blocks to long. I don't get that when playing the sound itself. Its the same for static and stream sounds.
Its not a problem when the sound itself starts to play with a little delay, but without blocking the whole main thread.

I understand there is a problem in doing what your trying to do, are you also saying that removing the seeking from the ov_open_callbacks() function is having no effect? it should make a difference...

Is this not a universal problem when trying to load anything mid-game? all the tutorials I've come across would suffer from this problem too.

I agree it would be nice have the opening of files farmed out to another thread but I can see it being quite a change to the current structure to do this.

The thread for streaming is only there to address the major problem of updating during a stall, to turn this into a management thread could likely open a can of worms

I'll have a think on it and see if theres a simple solution, but for now its down to the user to manage resource loading in a frugal manner.

Why are you needing to create sounds during rendering?

Because we are getting the soundfiles on demand from the server, and they get created during the runtime of the game, when the sound is finished downloading. It gives a very unpleasent feeling when the rendering stutters when a new sound being created.

Are on this issue or shoud I try it ? Because I need that resolved for our game and I think its a huge benefit. One a real case not every sound is loaded before the game actually starts, that would be a huge memory use.

I'm thinking about the best way to implement this at the moment but it may be worth trying to have a go yourself for now, I had a quick stab at it last night but it quickly got too complicated.

I'm a bit busy with work at the moment so not getting a lot of time to get my head around it, but it is in the pipeline..

damn my first try to move the ov_open_call to the boost thread does not change the problem... I need to profile it more.. There must be a way

Hmm, if you could find out that would be great, do you use the ov_test_open() call then?

Yes I am using the test call. Its working right now, but not perfect yet. The problem was the thread mutex was locked by the play and so it blocked the same ammount of time until the loading was finished. I need to improve and stress test it a bit.

Hey Highway, I've comitted an attempt at solving this problem, can you check it out for me and see it there are any issues. Much appreciated.

Thats some great news, I will test it right away when I am back on my machine. I will surely give you a report.

Ok ive testet the new version. It does not stall the rendering anymore, but the sound does not get played when the play is triggered before the file is finished loading.
It seams that it should be activated in the updatebuffer queue but the sound does not get added to the list. The best would be that it is activated when finished loading in the queue.

When I change this with the play() , it works very good
/*/////////////////////////////////////////////////////////////////*/
void OgreOggSoundManager::processQueuedSounds()
{
#if OGGSOUND_THREADED
boost::recursive_mutex::scoped_lock l(mMutex);
#endif
if (mQueuedSounds.empty()) return;

FileOpenList::iterator i = mQueuedSounds.begin();
while( i != mQueuedSounds.end())
{
// Open file for reading
(*i)->mSound->open((*i)->mFile);

// Prebuffer if requested
if ((*i)->mPrebuffer ) requestSoundSource((*i)->mSound);


// Automatically play if ready.
if ((*i)->mSound->mPlayDelayed){
(*i)->mSound->play();
}

// Remove from queue
delete (*i);
i=mQueuedSounds.erase(i);
}
}
/*/////////////////////////////////////////////////////////////////*/

I will test it now in our game framework. Thanks again Sticky!

I thought I'd taken care of that, basically if you call createSound() then immediately call playSound/play(), it sets a flag if the sound is not ready for reading, then in updateBuffers it checks this flag and calls play when its ready...

[Edit] Ah, after a quick look there may be a logic error there, I tested creating pre-buffered sounds which works, but it looks like if you don't specify pre-bufering then it may never call play() because the sound doesn't get allocated a source, your solution may be the best method. Thanks[/Edit]

It just works perfect! My attempt was not very good, it had a longer delay to play the soundfiles. But I use now the direct play(),pause(),stop() methods on the soundobject because the other ones on the soundmanager stalls the rendering again. I keep you updated.

I've committed a fix for the play() bug and also added the wav classes into the thread opening. I'll look at the SoundManager function delay soon.

I'm not sure what might be causing the delay with the SoundManager calls, it could be the mutex but they are definitely required, I've rearranged the play() functions to handle the delay first whch should slightly increase performance, don't know if it will eliviate the problem for you but you can try it...

Hi ,

I am experiencing the same issue, with my application.

As suggested above, i changed the ProcessQueuedSounds in my OgreOggSound sdk and copied the newly built dll into my project.

But my application crashes with this new OgreOggSound.dll.

I have no idea where i am going wrong.

Can some please help me with this issue??

Just to make things clearer i am using Ogre V 1.6.2 source ( VC9) .

Thanks in anticipation,
Regards,
Rohith H N

Hi There,

Whats the exact nature of your problem?

What version of the library are you using, SVN/Zip, version no.?

Hey Hi,

Sorry, i must ve mentioned the OgreOggSound version earlier.

My current version is 1.0 (OgreOggSound Source)

The issue here is whenever i create a sound at run-time , my application pauses for a second and then continues.
But the sound plays out perfectly (Without Delays or any other issues). The sounds that are being created are not streamed.

That when i found this topic on the forum and changed the ProcessQueuedSounds() function in the OgreOggSound Source as suggested by one of the posters.



But this is not working out for me.

BTW...I am not using any boost threads for now, but i m planning to add them in the near future.

Can u plz point where i am going wrong?


Regards,
Rohith H N

There will be a delay when creating sounds if not using BOOST, it loads the entire sound into memory immediately, there's no way around that unless you use streamed sounds.

You should preload these sounds before rendering, how big are the sounds?

Are you not using v1.14?