[osgaudio-users] continued problems with allocation of sources
Ross Bohner
I am still having difficulty with allocating over 64 separate SoundSources.
It appears there still is a limit on the number of different sources, it also appears the de-referencing of soundstates does not work
I have included a test program. It does require 70 different source files. Let me know if you want to test using my files and I'll email you the files directly.
The problems occur after allocated 64 sources, the 65th allocated source does not play yet the soundstate isPlaying() returns true, Also if you deallocate the 64th source then allocate a different source in the 64th spot, then the 64th source does not play.
The replaying of the source after it finishes works nice now as well as working alongside firefox.
I am using FMOD 4.3002 on osgAudio svn rev 36, red hat linux 5
--
Ross Bohner
Virtual Reality Applications Center
Iowa State University
Cell: 319-431-3806
http://rossbohner.com
--
You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
To post to this group, send email to osgaudi...@googlegroups.com.
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
Chris 'Xenon' Hanson
> I have included a test program. It does require 70 different source
> files. Let me know if you want to test using my files and I'll email you
> the files directly.
> The problems occur after allocated 64 sources, the 65th allocated source
> does not play yet the soundstate isPlaying() returns true, Also if you
> deallocate the 64th source then allocate a different source in the 64th
> spot, then the 64th source does not play.
only test on Windows currently, so if it doesn't fail there, I will just be wasting effort.
--
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
Doug McCorkle
Where did you end up on this issue? I think for the most part the
other issues have been resolved regarding FMOD in osgAudio. This one
seems to be the only remaining issue that has been reported.
Doug
On May 9, 2010, at 10:43 AM, Chris 'Xenon' Hanson wrote:
> On 5/8/2010 7:03 PM, Ross Bohner wrote:
>> I have included a test program. It does require 70 different source
>> files. Let me know if you want to test using my files and I'll
>> email you
>> the files directly.
>
> Well, it sounds like I'll need 70 source files to test it.
>
>> The problems occur after allocated 64 sources, the 65th allocated
>> source
>> does not play yet the soundstate isPlaying() returns true, Also
>> if you
>> deallocate the 64th source then allocate a different source in the
>> 64th
>> spot, then the 64th source does not play.
>
> Are you able to confirm that this fails on Windows and not just
> Linux? Because I can
> only test on Windows currently, so if it doesn't fail there, I will
> just be wasting effort.
>
--
Ross Bohner
Sent from the future
Doug McCorkle
you used and the sound files you used?
Doug
Ross Bohner
I have previously submitted the code highlighting this problem and I cannot send my test audio files as they are too large for this mailing list (4MB limit). If someone is willing to test my code then I can email them the audio directly. I have not tested this issue on Windows
I have not tested past v36. The comments on the subversion repo do not indicate this issue has been looked into. Has there been work in this area past v36? I have previously submitted the code highlighting this problem and enclosed is a set of sound files to test this problem. I have not tested for this bug on Windows
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
To post to this group, send email to osgaudi...@googlegroups.com.
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
--
Ross Bohner
Virtual Reality Applications Center
Iowa State University
Cell: 319-431-3806
http://rossbohner.com
--
Ross Bohner
Virtual Reality Applications Center
Iowa State University
Cell: 319-431-3806
http://rossbohner.com
McCorkle, Doug [VRAC]
From: osgaudi...@googlegroups.com [osgaudi...@googlegroups.com] On Behalf Of Ross Bohner [rossb...@gmail.com]
Sent: Monday, May 24, 2010 7:58 PM
To: osgaudi...@googlegroups.com
Subject: Re: [osgaudio-users] continued problems with allocation of sources
Chris 'Xenon' Hanson
> Can you post the sound files to your website?
you post a complete reproducible case, I can take a look at it.
--
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
Paul Martz
> On 5/24/2010 7:02 PM, McCorkle, Doug [VRAC] wrote:
>> Can you post the sound files to your website?
>
> Yeah. I don't think anyone wants to pay me to sit around and generate audio files. if
> you post a complete reproducible case, I can take a look at it.
>
Is there an issue open in the issue tracker for this?
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
Doug McCorkle
On May 25, 2010, at 2:37 PM, Paul Martz wrote:
> Chris 'Xenon' Hanson wrote:
>> On 5/24/2010 7:02 PM, McCorkle, Doug [VRAC] wrote:
>>> Can you post the sound files to your website?
>>
>> Yeah. I don't think anyone wants to pay me to sit around and
>> generate audio files. if
>> you post a complete reproducible case, I can take a look at it.
>>
>
> Is there an issue open in the issue tracker for this?
>
I do not think so.
Doug
Chris 'Xenon' Hanson
Some background:
FMOD doesn't share the same semantics as OpenAL -- you cannot configure settings like
volume gain on a sound that is not currently playing. OpenAL (and therefore osgAL) allowed
you to pre-configre things like volume gain prior to setting the sound playing.
To emulate this, all sound sin FMOD are created as already playing, but paused at the
beginning. In this state, their settings like volume gain can be adjusted and the
adjustments will be retained and adhered to when unpaused. Telling a sound to play is
really telling it to un-pause.
Therefore, every sound that exists in FMOD is technically "playing", but paused, and
consuming some resources.
FMOD normally exposes 32 hardware playback channels, and another 32 software playback
channels that are combined together and fed to the hardware as one channel. This is the
64-sound limit Ross discovered. The 65th sound simply had no resources to play through.
I increased the pre-set number of software channels to 100. If it is necessary to
increase this limit further, this can be done in AudioEnvironment.cpp,
AudioEnvironment::getSystem() around line 205-206.
Doug McCorkle
Thanks for resolving this issue. One more question, when we deallocate a source why is that source not available for new sounds? It seems that even if there is a 64 sound limit that after deallocating a few of the sounds that they should be available again until we hit the 64 limit. This does not appear to be the case. It seems this would still be an underlying issue with the new change to add 100 source limit.
Doug
Chris 'Xenon' Hanson
> Hey Chris,
> Thanks for resolving this issue. One more question, when we deallocate a source why is that source not available for new sounds? It seems that even if there is a 64 sound limit that after deallocating a few of the sounds that they should be available again until we hit the 64 limit. This does not appear to be the case. It seems this would still be an underlying issue with the new change to add 100 source limit.
I guess I haven't seen the circumstances of this problem. The description you sent
showed that once you hit >64 sources, it wouldn't play, but pressing the key a few times
to free some sounds and then load a new one allowed the new one to play. Is this not the
situation you're seeing? Or are we talking two totally different problems?
Doug McCorkle
On May 26, 2010, at 10:40 AM, Chris 'Xenon' Hanson wrote:
> On 5/26/2010 6:19 AM, Doug McCorkle wrote:
>> Hey Chris,
>> Thanks for resolving this issue. One more question, when we
>> deallocate a source why is that source not available for new
>> sounds? It seems that even if there is a 64 sound limit that after
>> deallocating a few of the sounds that they should be available
>> again until we hit the 64 limit. This does not appear to be the
>> case. It seems this would still be an underlying issue with the new
>> change to add 100 source limit.
>
> I guess I haven't seen the circumstances of this problem. The
> description you sent
> showed that once you hit >64 sources, it wouldn't play, but pressing
> the key a few times
> to free some sounds and then load a new one allowed the new one to
> play. Is this not the
> situation you're seeing? Or are we talking two totally different
> problems?
Here are the instructions for the test:
1. Copy the source file from Ross into the osgaudiomultiple example
2. Rename the file to osgaudiomultiple.cpp
3. Rebuild osgAudio
4. Create a test directory
5. unzip the sounds.zip file into the test directory (be sure the
sounds directory is in the test directory)
6. Run the new osgaudiomultiple example within the test directory
7. Press 1 64 times (Ross prints how many sources have been allocated
to the screen)
8. Press 2 ( the last sound will be played)
9. Press 3 to stop the sound
10. Press 1 to allocate sound 65
11. Press 2 (the sound will not be played) - this is a problem
12. Press 3
13. Press 5 5 times to deallocate 5 sources
14. Press 2 (a sound will be played)
15. Press 3 to stop the sound
16. Press 1 to allocate another sound
17. Press 2 ( the last allocated sound will not be played) - this is a
problem
You will notice on step 17 the new sound that is allocated will not
play. It seems that after deallocating 5 sources (step 13), which
should bring us back below the 64 sound limit, that the newly
allocated sound should play. Is this correct or are we
misunderstanding how deallocating works with FMOD and osgAudio?
Doug
Ross Bohner
//after setting up the test environment (Doug's 1-6)
7. loop 64 times {
- Press 1 (Allocate new sound)
- (optional) Press 2 (play last sound allocated)
- (optional) Press 3 (stop playing sound)
- Press 5 (de-allocate the sound)
//at this point there "should" be zero sources allocated
8. Press 1 to allocate a new sound
9. Press 2 - the newly allocated sound will not play
--
You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
To post to this group, send email to osgaudi...@googlegroups.com.
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
Douglas McCorkle
On May 26, 2010, at 11:05 AM, Ross Bohner wrote:
> The problem scenario can also be exhibited by this test:
>
> //after setting up the test environment (Doug's 1-6)
>
> 7. loop 64 times {
> • Press 1 (Allocate new sound)
> • (optional) Press 2 (play last sound allocated)
> • (optional) Press 3 (stop playing sound)
> • Press 5 (de-allocate the sound)
> }
>
> //at this point there "should" be zero sources allocated
> 8. Press 1 to allocate a new sound
> 9. Press 2 - the newly allocated sound will not play
Good point. Another way to state the problem is technically we do not
need to have 64 or more sounds allocated at once. Since deallocation
is not working as we understand things then having the ability to
allocate more than 64 sounds temporarily solves our problems. It seems
there may be another problem in addition to the problem of not being
able to allocate more than 64 sounds.
Doug
Chris 'Xenon' Hanson
I updated to the latest SVN, with my fixes, and ran the test exactly as stated above.
All tests worked without a problem on Vista-64 osgAudio/FMOD.
Did you test this after I checked in my last fixes? Because it works for me, post-fix.
> Doug
Ross Bohner
--
You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
To post to this group, send email to osgaudi...@googlegroups.com.
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.
Doug McCorkle
No. I would expect it to work. So...lets change the test. On..
1. instead of pressing 1 64 times press 1 132 times.
2. Press 1 to allocate sound 133.
3. The sound will not play.
4. Press 5 5 times to deallocate 5 sources
5. Pick up the steps on step 14 from above.
Like Ross and I both said it appears deallocation does not work and the current fix does provide more functionality but appears to not address the core issue of the problem Ross is describing. As both Ross and I described in follow up emails to the original one above, deallocation does not appear to actually deallocate an FMOD source OR Ross and I do not understand how deallocation is supposed to work in osgAudio. In either case it appears we need more information on how deallocation is supposed to work to fully understand what we need to solve the core issue of Ross's problem.
Doug
Chris 'Xenon' Hanson
>> Did you test this after I checked in my last fixes?
> No. I would expect it to work. So...lets change the test. On..
> 1. instead of pressing 1 64 times press 1 132 times.
> 2. Press 1 to allocate sound 133.
> 3. The sound will not play.
> 4. Press 5 5 times to deallocate 5 sources
> 5. Pick up the steps on step 14 from above.
Ok. I don't think I have 133 numbered sound files, but I'll copy/rename some and see how
it works then.
> Like Ross and I both said it appears deallocation does not work and the current fix does provide more functionality but appears to not address the core issue of the problem Ross is describing. As both Ross and I described in follow up emails to the original one above, deallocation does not appear to actually deallocate an FMOD source OR Ross and I do not understand how deallocation is supposed to work in osgAudio. In either case it appears we need more information on how deallocation is supposed to work to fully understand what we need to solve the core issue of Ross's problem.
Ok. I just need a solid failure case where I can see what's actually failing, so when it
didn't fail, I was kind of at a loss. I'll take a look at it.
Doug McCorkle
On May 29, 2010, at 9:10 PM, Chris 'Xenon' Hanson wrote:
> On 5/29/2010 8:01 PM, Doug McCorkle wrote:
>>> Did you test this after I checked in my last fixes?
>> No. I would expect it to work. So...lets change the test. On..
>> 1. instead of pressing 1 64 times press 1 132 times.
>> 2. Press 1 to allocate sound 133.
>> 3. The sound will not play.
>> 4. Press 5 5 times to deallocate 5 sources
>> 5. Pick up the steps on step 14 from above.
>
> Ok. I don't think I have 133 numbered sound files, but I'll copy/rename some and see how
> it works then.
>
>> Like Ross and I both said it appears deallocation does not work and the current fix does provide more functionality but appears to not address the core issue of the problem Ross is describing. As both Ross and I described in follow up emails to the original one above, deallocation does not appear to actually deallocate an FMOD source OR Ross and I do not understand how deallocation is supposed to work in osgAudio. In either case it appears we need more information on how deallocation is supposed to work to fully understand what we need to solve the core issue of Ross's problem.
>
> Ok. I just need a solid failure case where I can see what's actually failing, so when it
> didn't fail, I was kind of at a loss. I'll take a look at it.
You do have a solid failure case. The original test case before your patch. Another failure case would be to set the number of sources to 5 or something really small. Then try to allocate that number of sources and deallocate the number of sources and then allocate the sources and things will fail. Can you explain how deallocation works and why sources are not being reclaimed as Ross's original example points out?
Doug
Chris 'Xenon' Hanson
> You do have a solid failure case. The original test case before your patch. Another failure case would be to set the number of sources to 5 or something really small. Then try to allocate that number of sources and deallocate the number of sources and then allocate the sources and things will fail. Can you explain how deallocation works and why sources are not being reclaimed as Ross's original example points out?
While at a cookout yesterday, it occurred to me what the problem likely is.
There's nothing special about deallocation as far as I know, it's just failing to
deallocate in one circumstance because of FMOD's unusual implicit reference-counting that
isn't really reference counting.
A paused (or allocated but not yet playing) source that is de-allocated in osgAudio is
not triggering FMOD's usual auto-release mechanism. I think I need to simply force the
issue by stopping the paused source in osgAudio's deallocation, so FMOD will auto-release it.
I will check this later today, but wanted to give you this update. It should be a
trivial fix.
Douglas McCorkle
On May 31, 2010, at 2:07 PM, Chris 'Xenon' Hanson wrote:
> On 5/29/2010 8:16 PM, Doug McCorkle wrote:
>> You do have a solid failure case. The original test case before
>> your patch. Another failure case would be to set the number of
>> sources to 5 or something really small. Then try to allocate that
>> number of sources and deallocate the number of sources and then
>> allocate the sources and things will fail. Can you explain how
>> deallocation works and why sources are not being reclaimed as
>> Ross's original example points out?
>
> While at a cookout yesterday, it occurred to me what the problem
> likely is.
>
> There's nothing special about deallocation as far as I know, it's
> just failing to
> deallocate in one circumstance because of FMOD's unusual implicit
> reference-counting that
> isn't really reference counting.
>
Great. This is good information to remember for the future.
> A paused (or allocated but not yet playing) source that is de-
> allocated in osgAudio is
> not triggering FMOD's usual auto-release mechanism. I think I need
> to simply force the
> issue by stopping the paused source in osgAudio's deallocation, so
> FMOD will auto-release it.
>
Ahhh. This makes sense.
> I will check this later today, but wanted to give you this update.
> It should be a
> trivial fix.
Good deal. Thanks.
Doug
Doug McCorkle
I tried the new code with the 100 virtual sources commented out and
still ran into problems. I started looking at a couple of things and
there does not appear to be any explicit instructions on how to
deallocate a channel other than at program shutdown. I thought that
was interesting. Also, in SourceFMOD.cpp we appear to allocate a
StreamFMOD but never appear to deallocate it. Is this correct? I see
in the FMOD docs that Sound does have a release method which we call
in the StreamFMOD class destructor but I am not seeing where the
wrapper class is being deallocated. Could this be part of our problem?
Doug
Doug McCorkle
Some more thoughts on this one. I dug some more and realized that the
OSG smart pointers are managing the sound pointer so there probably is
nothing that we are doing wrong on that front.
After ponder more of the FMOD docs it really does seem that FMOD is
not setup to "delete" a channel to be "reallocated" for another
channel. It seems this is possible but the intended use is for the
user to keep track of ALL channels allocated and then reuse an used
channel OR allocate a bunch of channels and maintain the playback
state of each channel. Anyway, all of that to say that I am not sure
we can really deallocate a channel at run time to adjust the number of
virtual voices available to the user. It seems we should set the
number of virtual voices very large and let the user adjust it if they
need more than what we have initially preconfigured. Do you agree/
disagree?
Doug
Chris 'Xenon' Hanson
> Hey Chris,
> I tried the new code with the 100 virtual sources commented out and
> still ran into problems. I started looking at a couple of things and
> there does not appear to be any explicit instructions on how to
> deallocate a channel other than at program shutdown. I thought that was
> interesting. Also, in SourceFMOD.cpp we appear to allocate a StreamFMOD
> but never appear to deallocate it. Is this correct? I see in the FMOD
> docs that Sound does have a release method which we call in the
> StreamFMOD class destructor but I am not seeing where the wrapper class
> is being deallocated. Could this be part of our problem?
Ok, I'm working on this this afternoon and hope to have some more answers.
Doug McCorkle
On Jun 2, 2010, at 2:34 PM, Chris 'Xenon' Hanson wrote:
> On 6/1/2010 8:23 AM, Doug McCorkle wrote:
>> Hey Chris,
>> I tried the new code with the 100 virtual sources commented out and
>> still ran into problems. I started looking at a couple of things and
>> there does not appear to be any explicit instructions on how to
>> deallocate a channel other than at program shutdown. I thought that
>> was
>> interesting. Also, in SourceFMOD.cpp we appear to allocate a
>> StreamFMOD
>> but never appear to deallocate it. Is this correct? I see in the FMOD
>> docs that Sound does have a release method which we call in the
>> StreamFMOD class destructor but I am not seeing where the wrapper
>> class
>> is being deallocated. Could this be part of our problem?
>
> Ok, I'm working on this this afternoon and hope to have some more
> answers.
I wanted to check in to see if you have uncovered anything in regards
to this issue?
Doug
Chris 'Xenon' Hanson
> After ponder more of the FMOD docs it really does seem that FMOD is not
> setup to "delete" a channel to be "reallocated" for another channel. It
> seems this is possible but the intended use is for the user to keep
> track of ALL channels allocated and then reuse an used channel OR
> allocate a bunch of channels and maintain the playback state of each
> channel. Anyway, all of that to say that I am not sure we can really
> deallocate a channel at run time to adjust the number of virtual voices
> available to the user. It seems we should set the number of virtual
> voices very large and let the user adjust it if they need more than what
> we have initially preconfigured. Do you agree/disagree?
I don't know that that's true, if I'm interpreting what you're saying correctly. From
the FMODEx help file, Getting Started chapter, Loading and playing section:
You do not need to store the channel handle if you do not want to.
You do not have to 'free' or 'release' a channel handle. Channels come from a pool which
you created by specifying a channel count in System::init. Channel handles get re-used if
old sounds have stopped on them. If all channels are playing, then one of the existing
channels will get stolen based on the lowest priority sound. Make sure this doesnt happen
by simply increasing the channel count in System::init.
A channel becomes invalid once it is finished playing. This means you can't update it, and
doing so would be pointless anyway becuase it isn't going to start again. Referencing a
stopped channel will most likely result in an FMOD_ERR_INVALID_HANDLE.
I did some more tracing, and I believe the problem lies at line 306 of SoundManager.cpp.
The SoundManager cleverly tries to recycle Sources, keeping them in the
m_available_soundsources pool. Whether this is necessary or not is open to debate, but it
does. Anyway, as a result, if the Source hasn't finished playing when it is recycled, the
"stop" on 306 is really interpreted as "pause". I interpret stop as pause I thought some
examples used "stop" but then wanted to replay or otherwise modify the Source and reuse
it. STOPping an FMOD sound deallocates the Channel, losing access to the playback position
state, volume state, etc. So, I implemented stop as pause, which retains the state. The
destructor now executes an FMOD stop, but in the case of the recycles Sources, it never
destructs, and therefore FMOD never releases the unplayed, paused sound.
I believe if the sounds had played to the end, this will not be an issue.
So, the solution is probably to make sure that Source::stop() can really be mapped over
to FMODChannel::stop(). We'd need to make sure that this fits with the "stop means
release" semantics dictated by FMOD, and to do so, one would need to examine all uses of
Source::stop() to see what their expected post-stop behaviour is.
Alternately, we could leave Source::stop() as a pause equivalent as it is now, and try
to ensure that when a Source is recycled that it gets properly released. Maybe this could
be done when the assignment of the new sound is done, but I expect no matter where we do
the forced cleanup, we'll need some new, semi-private method to force an FMODChannel::stop
if Source::stop continues to really be pause.
I haven't made any of these changes yet, but I believe this captures the essence of the
problem and I can try to fix it whichever way seems preferable.
Doug McCorkle
I will go with whatever method you all think is best.
Doug
Chris 'Xenon' Hanson
> I will go with whatever method you all think is best.
I made a fix that seems even better in all ways, and will check it in shortly.
Doug McCorkle
This works great! Thanks for tracking this down. I was wondering if
you could add some code comments or post some info here on the list
about what you were able to figure out so that we do not lose what you
learned.
Doug
Chris 'Xenon' Hanson
> This works great! Thanks for tracking this down. I was wondering if you
> could add some code comments or post some info here on the list about
> what you were able to figure out so that we do not lose what you learned.
Sure. I'll summarize here. Basically, since the actual destructor _WAS_ setup to clear
out the resource leak (which was my previous fix), I didn't need to do any more fixing
there -- it wouldn't help because the Source recycling in osgAudio doesn't destruct the
Source objects. So, I realized that the real problem was that assigning a NEW sound to an
existing source could leak, if that source was still playing (and possibly paused). So I
added de-allocation (in the form of an FMOD stop()) where the creation of a new FMOD sound
and assignment into the Source's internal pointer was done. This was a design oversight of
mine from the start. now it is fixed, and all is well.
I'm going to blame FMOD's unusual resource management for throwing me a curve here. I'm
normally a very rigid manual allocation and deallocation kind of guy. It took me a long
time to be comfortable with OSG's own ref ptrs. FMOD's even looser invisible ref counting
scheme leads one to be sloppy, because you think FMOD "has it all covered" but it doesn't,
really. You still have to be very careful about ensuring FMOD's ref counters can do their job.
Doug McCorkle
On Jun 12, 2010, at 11:37 AM, Chris 'Xenon' Hanson wrote:
> On 6/12/2010 6:47 AM, Doug McCorkle wrote:
>> This works great! Thanks for tracking this down. I was wondering if you
>> could add some code comments or post some info here on the list about
>> what you were able to figure out so that we do not lose what you learned.
>
> Sure. I'll summarize here. Basically, since the actual destructor _WAS_ setup to clear
> out the resource leak (which was my previous fix), I didn't need to do any more fixing
> there -- it wouldn't help because the Source recycling in osgAudio doesn't destruct the
> Source objects. So, I realized that the real problem was that assigning a NEW sound to an
> existing source could leak, if that source was still playing (and possibly paused). So I
> added de-allocation (in the form of an FMOD stop()) where the creation of a new FMOD sound
> and assignment into the Source's internal pointer was done. This was a design oversight of
> mine from the start. now it is fixed, and all is well.
>
> I'm going to blame FMOD's unusual resource management for throwing me a curve here. I'm
> normally a very rigid manual allocation and deallocation kind of guy. It took me a long
> time to be comfortable with OSG's own ref ptrs. FMOD's even looser invisible ref counting
> scheme leads one to be sloppy, because you think FMOD "has it all covered" but it doesn't,
> really. You still have to be very careful about ensuring FMOD's ref counters can do their job.
I understand now. Are there any other places in osgAudio we need to double check in regards to this new information? FMOD really is not managing the memory for us which sort of stinks. I suppose that means we will have extra guards throughout the code for FMOD use.
Doug
Chris 'Xenon' Hanson
> I understand now. Are there any other places in osgAudio we need to double check in regards to this new information? FMOD really is not managing the memory for us which sort of stinks. I suppose that means we will have extra guards throughout the code for FMOD use.
It is possible. I'll think about it and check into it in a couple of days.