Correct way of construct / destroy of OgreOggSoundManager

What is the correct way of construction and destroing of OgreOggSoundManager object?
I use

sound_mgr = OgreOggSound::OgreOggSoundManager::getSingletonPtr();
sound_mgr->init();

for construction (after creating Ogre::Root) and

sound_mgr->stopAllSounds();

for destroing (before Ogre::Root deleting)

This produces no errors but as I understood from other topics of this forum, I must manually destroy OgreOggSoundManager object:

delete sound_mgr;

When I try to call 'delete sound_mgr;' or 'sound_mgr->destroyAllSounds();' before 'sound_mgr->stopAllSounds();' the error "access violation" is occured in
OgreOggSoundManager::_processQueuedSounds.


I'm using OgreOggSound v1.17 (multithreaded build with boost 1.42), Ogre v 1.71 and VS2005 SP1

Hi there,

Construction/destruction is handled automatically, there is no need to to call stopAllSounds() or delete.

Hi, stickymango,
thanks for your replay.
I exclude the manual deletion of the OgreOggSoundManager and manual stopping of all sounds before destroing Ogre::Root.
It works fine but I still have a small problem.
I want to change the screen resolution during game running. So I must destroy Ogre::Root and create another one.
So I write code like this:

ogre_root = new Ogre::Root;
sound_mgr = OgreOggSound::OgreOggSoundManager::getSingletonPtr();
sound_mgr->init();
.................................................................................
delete ogre_root;
sound_mgr = OgreOggSound::OgreOggSoundManager::getSingletonPtr();
sound_mgr->init();

sound_mgr->createSound("Sound1", "sound1.ogg");
sound_mgr->getSound("Sound1")->play();

OgreOggSoundManager recreated and reinitialized correctly and my sound resources ("sound1.ogg") recreated correctly but no sound can I hear when try to start play.
I use threaded build of OgreOggSound. Maybe switching to the single-threaded version will help?
I want to put all scene, sound and input devices' update calls in the first thread and put game logic in the second thread.

One more small question.
I have rather long WAVE sound file and I want to restart this sound during its playng:

sound_channel->play();
...................................

sound_channel->stop();
sound_channel->setPlayPosition(0);
sound_channel->play();

Sometimes it works well but sometimes no sound produced after second 'play' call. Sometimes I hear only strange sizzle instead of my sound.

I've never tried to destroy and recreate Ogre::Root before, I don't see why there would be a problem but maybe there is, is there anything in the log file?

I'll try and set up a test program..

Regarding restarting your sound, it should be sufficient to just call stop(), as by default this resets the play position to 0 anyway so:
play();
stop();
play();
:
:

The log file contains only diagnostics messages:

15:34:00: Loading library .\OgreOggSound_d
15:34:00: Installing plugin: OgreOggSound
15:34:00: MovableObjectFactory for type 'OgreOggISound' registered.

15:34:01: *****************************************
15:34:01: *** --- Initialising OgreOggSound --- ***
15:34:01: *** --- OgreOggSound v1.17 --- ***
15:34:01: *****************************************
15:34:01: *** --- OpenAL version 1.1
15:34:01: *** --- AVAILABLE DEVICES --- ***
15:34:01: *** --- Generic Hardware
15:34:01: *** --- Generic Software
15:34:01: *** --- Choosing: Generic Hardware (Default device)
15:34:01: *** --- OpenAL Device successfully created
15:34:01: *** --- OpenAL Context successfully created
15:34:01: *** --- SUPPORTED FORMATS
15:34:01: *** --- AL_FORMAT_MONO16 -- Monophonic Sound
15:34:01: *** --- AL_FORMAT_STEREO16 -- Stereo Sound
15:34:01: *** --- AL_FORMAT_QUAD16 -- 4 Channel Sound
15:34:01: *** --- AL_FORMAT_51CHN16 -- 5.1 Surround Sound
15:34:01: *** --- AL_FORMAT_61CHN16 -- 6.1 Surround Sound
15:34:01: *** --- AL_FORMAT_71CHN16 -- 7.1 Surround Sound
15:34:01: *** --- EFX NOT Detected
15:34:01: *** --- XRAM NOT Detected
15:34:01: *** --- Created 63 sources for simultaneous sounds
15:34:01: *** --- Using BOOST threads for streaming
15:34:01: *** --- Recording devices available:
15:34:01: ***--- 'Aureal Audio'
15:34:01: ***--- 'NVIDIA(R) nForce(TM) Audio'
15:34:01: *****************************************
15:34:01: *** --- OgreOggSound Initialised --- ***
15:34:01: *****************************************

15:34:09: Uninstalling plugin: OgreOggSound
15:34:09: Plugin successfully uninstalled
15:34:09: Unloading library .\OgreOggSound_d


For restarting sound it SHOULD be sufficient to call stop() and play() but it doesn't work
Moreover the error is irregular: three or four times it works fine and the 4th or 5th time gives the error.
After error it works fine several times again. After that - next error.
I tried to use:

pause();
setPlayPosition(0);
play();

It gives the same result.

What type of sound is this?

static/streamed?

wav/ogg?

All the stop functions reset to the beginning:

Static sounds
alSourceStop(mSource);
alSourceRewind(mSource);
Ogg stream
// Jump to beginning if seeking available
if ( mSeekable )
{
ov_time_seek(&mOggStream,0);
}

Wav stream
// Reset stream pointer
mAudioStream->seek(mAudioOffset);
So I don't understand why thats not working

Hi again,

I think I've located the bug.

The bug occurs with short and long sounds, wavs and oggs, streamed and non-streamed, looped and non-looped.
I've investigated the behavior of long (4 secs) 22050 Hz WAV file.
I think that all kinds of bug behavior can be described in single common way.
The play cursor of sound channel is sometimes positioned incorrectly when user called stop().
Play cursor can jump to zero offset (that is correct) or non-zero offset, that can take values like 1 second,
0.5 second and others.

When I tried single-threaded build of OgreOggSound the problem disappears at all for short sounds. For long
sounds it still can be possible wrong behavior: sound stopped correctly but doesn't started by next call to 'play'
next calls pair to 'stop/play' functions produces correct result. It is a bug of course but it is produced rather rare.
So I think the main bug is in code chunks that provide multi-threading support and the small bug is anywhere else

I'm using latest OgreOggSound v 1.17, latest Ogre 1.71, BOOST 1.42.0, MSVS2005 SP1 under Windows XP SP3
If you need any info from me for debugging, let me know.

I have one more question.
In single-thread mode is it vital to pass to OgreOggSoundManager::update ( time )
precise value of current time? As I unserstood from source code, the value of 'time' argument is 'logical' time:
it is used only for fade effect calculation and is not used for sound buffer's write cursor positioning.


P.S. The bug with OgreOggSoundManager recreation (when changing display resolution parameters) disappears too

Hi Cid,

Thanks for looking into this, it does seem like there could be something up with the threaded messaging system somewhere causing some random results, I'll have to set aside some time to take a look.

As for your question, you are correct that OgreOggSoundManager::update() takes any time value you pass it and ONLY uses this to control fades, NOT sound buffer updates.

Thanks for your help so far!

I'm glad to help to hunt some bugs
and thank you for your fast help!

Hi there,

Had a quick check of the play() / stop() / play() issue and wasn't able to reproduce your problems, I did however come across an issue when using setPlayPosition() with an OGG file, which led me to two bug fixes so now calling stop() / setPlayPosition(0.f) / play() now functions as expected.

The only difference I see with your setup is the sound hardware available, I don't have any on my current test machines, I'm therefore running 'Generic Software' mode rather then 'Generic Hardware', maybe this is causing issues?

If you have a test app I could use that would be great, or maybe there's something about your sound files that isn't being handled correctly, maybe you could supply a problem file I could use that in my test app?

I haven't had time to create a test app for destroying / recreating Ogre::Root yet so I'll let you know about that at a later date.

Sorry for no solution yet.

Hi, stickymango!

I'll prepare code sample which produces the error and my sound files but I think it'll be no earlier than tomorrow.

Hi, stickymango!
Sorry for a delay.
I've prepared the smallest example that I can
It only creates Ogre, OIS and OgreOggSound, loads sound file and plays it on mouse click event. If you'll click mouse rather fast the error will come.

[attachment=0]Sample.zip[/attachment]

I also load some graphical objects (robot.mesh from Ogre package) but I think this action is not mandatory for error producing.
When creating OgreOggSound, I use dafault sound card (GENERIC hardware: onboard nVidia nForce sound card).

Hi Cid,

I tried to use your sample but there were a few things missing to get it to compile, events_translator?

Anyway, I modified my test demo app to do the same thing I think, I create the same two sounds with the same properties and link a mouse released event to stop()/play() splash.wav, however I cannot reproduce the problem.

Have you tried using the 'Generic Software' implementation to see if thats different, I don't have any dedicated sound hardware available unfortunately but that appears to be the only difference in setup I think.

Maybe I could upload my test demo and you could test it to see if it behaves the same?

Hi, stickymango!

I've corrected errors in my sample
I attach not only sources but executable too.
Threaded version of OgreOggSound gives error.
Press 'space' to recreate Ogre::Root and 'Esc' to exit.

[attachment=0]TestOgreOggSound.zip[/attachment]

Upload please your sample and i'll test in on my computer.

Hi Cid,

An unrelated issue, has pinpointed a memory corruption problem which has been resolved, I'm thinking it may be causing your random issues too, so if you can update your SVN version and try again maybe its now solved...

I'll get around to trying your sample soon.

HTH

Hi, stickymango.

I tried new version (ogreoggsound-v1.18.zip). The error is still there.

Fixed in SVN

I cannot recreate the stop()/play() issue your having unfortunately though

Maybe you click mouse very quickly?
Try to click mouse with about 0.5 - 1 second period and do such 30-40 times. So you will be able to keep an eye on the program's behavior.
Sometimes you must hear "no sound" on next mouse click.
This error disappears when switching to single-thread mode. So I don't think that the reason is hardware features.

Ah right, yes I was clicking quickly, I'll try as you suggest and report back.