[futurebasic] sounds and memory

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : September 1998 : Group Archive : Group : All Groups

From: Lucy24@...
Date: Sun, 27 Sep 1998 14:53:08 EDT
It's been a while since I've posted a really substantive problem, but here's
one to chew on. Consider this excerpt from my globals list:

   DIM gameSound&
   DIM extraSound&
   DIM phonyVar&
   DIM backSound1&
   DIM phonyBack.8
   DIM backSound2&
   DIM backSound3&

-- gameSound& is a handle to a sound resource. It is loaded when needed,
locked, played in channel 1 (in gameplay terms, foreChannel&) and then kept in
memory until the handle is needed for the next sound.
-- extraSound& is exactly the same thing except that its sound goes to the
other channel, backChannel&
-- backSound1& and its siblings are loaded as a group--different scenes use
one, two or all three--and are used for background-sound looping. When no
longer needed they are unlocked & disposed, whether or not a new group is

The problem: when one or another of these five sounds (which one, exactly,
will depend on the individual compile) has been loaded into memory, the
program crashes at quit. If "Apple Menu Options" (OS 7.5.5) is active, it also
crashes on _any_ menu-bar click (possibly the first time I've _ever_ gotten
useful information out of ConflictCatcher!); MacsBug tells me that one of the
menus has disappeared from memory.

Things I've excluded:
--it doesn't matter whether the sound in question has actually been _played_
or simply loaded into memory
-- what specific sound resource is involved (each of the five handles calls on
a different pool of sounds, with no overlap)
-- how large the sound is, though longer sounds may be truncated (a warning
that things will go bad)
-- whether the sound lives in an external resource file or in the app itself
-- whether it has been subsequently disposed or is still in memory
-- whether the app explicitly disposes of sounds at quit
-- whether it's a proper quit or simply cmd-period END
-- whether I'm running a compiled app or within FB
-- in the case of the menu bar, it doesn't matter what code (or none at all)
would be executed; it's the physical click
-- larger-scale wonkies don't seem to be at issue; all this happened both
before and after I re-initialized my hard drive

...which brings us to the phonyVar. These are, as you've all guessed,
bandaids. Slipping a phonyVar& into the appropriate location in the globals
list makes the problem go away. I try four bytes& first; if that isn't enough
I go to eight.8. (Six may have been enough; I just haven't tried it.) To
anticipate the obvious question: as far as I've been able to establish, no
bogus value has ever slipped into any phonyVar. (No, uh, blood on the
bandaid.) And, of course, that's "go away" in the sense of the monster that
used to be under the bed and has now relocated to the hall closet.

Since then I've come up with a bandaid that works even better: shift
everything but gameSound& into
   DIM backSound&(3)
...which, I think, moves the whole thing into a completely different part of
memory (where the sound handles are immediately followed by several important
global arrays that behave exactly as they ought).

But these are still bandaid fixes. Can anyone give any insight into what the
_real_ problem is?