I’m a bit confused about the meaning of the error message "An invalid object handle was used". The thing is that I keep getting it every now and then when I try to apply 3d attributes to certain events but I can’t figure out why. If I for instance have an event and execute event->getState it won’t complain and it returns a valid value but if the following execution is event->set3DAttributes (with a valid position for instance) it will say "An invalid object handle was used". Why is this? What am I missing here? I have read somewhere that the message should be more informative in future releases of FMOD but nevertheless I wonder why I sometimes can’t apply my 3d attribs. Worth noting is that before I try to apply 3d attribs I make sure that the event has mode=FMOD_3D which rules out the possibillity that I try to set 3d attribs to a 2d sound.
- Frohagen asked 11 years ago
I am handling EVENT_CALLBACKTYPE_STOLEN so there should never be a case where I do something with a stolen an thus invalid event. Before I implemented this my code crashed almost instantly since alot of event got stolen here and these so I’m pretty sure I have it all covered up now since it’s a stable as FMOD. What I’m a bit suspcious about is that a channel not an event gets stolen and I can’t seem to find a way of catching this and settings the event as invalid. Also, I’m a bit confused about how to handle 3d attributes with respect to min/max distance. I read somewhere that it was a bad idea to have a low max-distance and we do have that on one of the spamming events. Maybee that’s the reason but if so why should it? Why can’t I have a low max-distance? I though that was a smart idea if I want to really silence some sounds outside a ceratin radius.
We are in the middle of a delivery here and I’m not allowed to update FMOD until it’s done so I can’t verify that yet. If you missed it in my earlier posts we are using 4.4.41 so I guess alot of things may have been fixed since then. Is it possible for you to verify that this is a known bug that has been fixed or should I just hope for the best the day I upgrade
[quote="Ljudas":3cpesimj]Also, I’m a bit confused about how to handle 3d attributes with respect to min/max distance. I read somewhere that it was a bad idea to have a low max-distance and we do have that on one of the spamming events. Maybee that’s the reason but if so why should it? Why can’t I have a low max-distance? I though that was a smart idea if I want to really silence some sounds outside a ceratin radius.[/quote:3cpesimj]
If this is obvious forgive me, but if you are using Logarithmic volume fall-off and setting a low max-distance, no matter how far away the sound is it will sound as though it is at max distance. We had a problem with this because the logarithmic fall-off didn’t get quiet fast enough and our sound designer said it is standard to have a radius of sound, beyond which you hear nothing. So, we use a Linear fall-off. With linear your max distance IS a distance beyond which you can’t hear the source.
- droberts answered 11 years ago
Ok you actually said ‘max playbacks’ which is exactly the term in the event properties, thats why i thought that.
Do you have a problem then? You aren’t really giving much info here, all i know is that you have got an error, i’ve explained a few times why you get it, is it ringing any bells?
The rolloff isn’t really the issue here but rather the error messages. And actually, after some messing around, I have managed to remove some of them by a) increasing max_channels from 64 to 256 (removed most of the channel stealing for obvious reasons) b) didn’t set any 3d attribs on events where no channels were playing. A new problem appeared though and that is that if an event gets no 3d updates since there are no channels playing and if these channels aren’t playing since the event is outside max-distance then i will never hear the sound again until i try to replay it. This is getting very messy and I’m still not free from all thoose error messages so please, please, please fmod guys, can you help me out here?
Ok I realize now what your problem is, it just triggered as there is one case that I forgot about..
You’re using INFOONLY, so you can’t get property objects from it, you can only use the most basic functionality, otherwise it would have to allocate memory. It does not do this with the infoonly flag.
It is mainly for ->
FMOD_RESULT F_API getInfo(int *index, char **name, EVENT_INFO *info);
That is your problem. I’ll update the error to say something event specific for the next time.
handles are reference counted, and if a channel or event is stopped, then it is no longer valid, same as if you exceeded maxplaybacks and your new event handles started overwriting slots used by previously playing event handles (ie all event steal modes).
Volume or 3d distance has nothing to do with this, I have never heard of a case where simply going outside of maxdistance makes a handle go invalid, this simply doesnt happen. Maybe the voice count was too low in (Event)system::init so there was actual low level channel stealing going on, replacing quiet sounds – thats why you increase the channel count so that all your channels can successfully play.
Actually scratch what i said, it looks like you can get parameter info, I just tried it and it works. This still leaves my original question though.
What you CAN’T do is start/stop the event, as EVENT_INFOONLY doesnt allocate any instance memory (thats the point), so its just those 2 functions that will return FMOD_ERR_INVALID_PARAM. I’ve just changed this to FMOD_ERR_EVENT_INFOONLY.
Well, the problem as I stated earlier that I do catch the event stealing by using the callback so I can’t be using any stolen events. Also I make sure to zero any pointers to events that have finished playing both by checking the playstate and the finished-playing callback. So, if you report all stealing there can’t be a case where I use a stolen event. Still I get the error and most interesting of all is that I only get it if I try to set 3d attribs. If I do a getState or whatever right before I do a set3DAttributes then that would work so there definatelly can’t be anything wrong with the event-handle. About channel-stealing then. I have currently set max_channels to 512 and at the moment we don’t have that many sounds in the game and we can’t possibly be close to this number. By the way, how are thoose channel allocations handled? Does every event in a eventgroup get a set of channels allocaated when loading the group or does it allocate the channels when getting the event?
I have reproduced this again.
I call getEventByIndex – it returns ok
I call getInfo (to check if sound is looped) – it returns ok
I call getPropertyByIndex and it fails.
First fail occurs on 2242 call.
Hm… after that some calls ok, and at 2340 call it starts to fail always.
May be problem in multiple projects, that I use?.. Anyway, getEventByIndex doesn’t fail.
It must work, right? Or there is some condition when it can fail?..
I think, engine can know – is sound 2d or 3d, even on sound loading…
May be you will put this info in event info..?
On loading I call getEventByIndex for each event and
check if sound 3d, after some calls fmod begins fail on getPropertyByIndex(FMOD::EVENTPROPERTY_MODE, &mode).
It returns FMOD_ERR_INVALID_HANDLE.
May be it’s same problem… Anyway why this occurs and what to do to avoid this?
I still haven’t got a satisfying answer to my original question why I keep getting FMOD_ERR_INVALID_HANDLE on some calls and not others using the very same handle. Is it just pure luck, or is there some more logical explaination to it? For some reason it occurs to set3DAttributes 99% of the cases so a not very wild guess would be that there is some kind of connection to the sound being 2D or 3D. Please, help me out here cause as long as I get these kinds of errors I can’t expect FMOD to be working correctly and thus can’t really see if the problems that appear apart from this one is caused by FMOD or the code using it.
I also get this message under similar conditions:
The specified channel has been reused to play another sound
I do catch and handle the callbacks EVENT_CALLBACKTYPE_STOLEN and EVENT_CALLBACKTYPE_EVENTFINISHED. Is there anything else I should check for to be certain I’m not using a "dead" event.
My guess is that the handle is perfectly valid otherwise it would complain on all functions and that another error message is supposed to be spammed but isn’t for some reason. I know that the error messages have been updated recently so if I would have tried the latest version I might have got another message. Why I’m not updating right now is because we are in the middle of an important deliverable and it’s a no-can-do to update any middleware whatsoever right now.
I noticed a little detail that might be of some help. One of the events that are spamming FMOD_ERR_INVALID_HANDLE when trying to set 3d attribs consists of three layers. In the game, when the error appears, they aren’t panned as a unit but instead the third layer (consisting of a tiny little sound) always appear in the wrong speaker. We have tried using both compressed and uncompressed data so I don’t think its one these XMA related errors but rather something related to pan-level which we are using for the event.
I do have an idea about some of these messages. I have tracked one of the sound that are spamming and it seems like it spams "An invalid object handle was used" when the sound is outside max-distance. Could this be correct? Does this mean that I have to check if an event is outside max-distance before I try to set3DAttributes? Should I even stop the event? Or is this done automatically and if so then how do I catch it?
Please login first to submit.