Freeing sounds?

BlitzMax Forums/BlitzMax Programming/Freeing sounds?

GfK(Posted 2007) [#1]
Am I right in thinking 'sound = Null' will 'free' a sound?

I'm still having all sorts of bother with Blitzmax's sound system. Sound stops working after switching from front-end to game and back *exactly* ten times. I've pretty much ruled out that its nothing to do with the way I'm handling sound channels, so I'm starting to look for other possible problems.

The only thing thats apparent is that there's something linear that I'm doing wrong. I just can't work out what it is.


GfK(Posted 2007) [#2]
Well, this is most peculiar.

I've fixed the problem, but it was nothing to do with sounds or channels.

I have a custom type with a timer in it. There is only one instance of this type at any given time. Its possibly worth notice that, if any of you have a timer within a type, then simply calling "myType = Null" may well cause GCCollect to get rid of the instance, but it does NOT get rid of the timer within (even though you no longer have any access to it).

Why this was preventing sounds from working I'm not entirely sure, but its fixed now.


Gabriel(Posted 2007) [#3]
I must admit I dislike the inconsistencies of garbage collection in BMax. Some things have to be explicitly destroyed and some just have to go out of context to be collected automatically. I know I'm going to face this when I'm using external libraries, but it really would be nice if the standard modules - as far as possible - stuck to one technique or the other.


sswift(Posted 2007) [#4]
One big problem is that the special method that's suppsoed to be called when something is freed is not called when it is freed, and may never be called. This kind of makes it impossible to say, remove sprites from the rendering pipeline when they are no longer needed. Of course, it also is impossible to do that because there are no weak references which don't contribute to the reference count, meaning because the sprites are in a rendering list in the first place they never would run out of pointers to them to begin with.

Oh and the whole freeing stuff when it goes otu of reference? I've been using BlitzMax for a year now and I'd say I'm fairly expert at it at this point, and I still find it really hard to keep track of what I still have pointers to. As elegant as this method is, the inelegant method is by far less confusing, and having the two mixed has been a recipe for disaster in my code on more than one occasion.

I say explicitly requiring things to be freed is the way to go. Then you don't even need weak references to just confuse matters more.


Grey Alien(Posted 2007) [#5]
Yeah all my types have a Kill() funciton which I always call as I'm used to manually cleaning up. Then if Imiss something I hope the GC gets it, but if I'm in any doubt, I manually clean...


GfK(Posted 2007) [#6]
I think doing it manually is the best way, given the aggravation GCCollect caused me yesterday. I wasted five hours chasing an audio bug which, in the end, wasn't even down to the way I was implementing sound.

I'm still not sure why stray timers would stop sound from working. But honestly I don't really care why. I know now.


Jake L.(Posted 2007) [#7]
I'm doing it like Grey Alie. Everything that smells like an object will be manually destroyed by xyz=null (and if possible a xyz.Clear() before that). I also clear arrays with pointers with ar=ar[..0]. So far the only issues I got were caused by homemade erros and could be easily fixed once known ;)

The only thing I leave unattended are local objects inside methods/functions.


Grey Alien(Posted 2007) [#8]
Yeah that's true, I leave locals alone, it's only my types and their fields that I free up.


skidracer(Posted 2007) [#9]
Just found out that audio channels fall into the same boat as gadgets and timers, as in due to the nature of "ownership" the objects will never be collected.

From first glance there doesn't actually seem to be anyway of freeing an unstarted channel but I may have missed something. It would certainly be nice if all three shared some sort of free / stop methodology by extending something like TResource so it was more evident that the system underneath has it's own reference to the object, or at least should have...

My other problem is whenever I see a reference to sound I think AudioSample not AudioChannel....