rSounds - affect on available free memory

[jefbla@bconnex.net (Jeff Blakeney)]

lstrand@netcom.com (Leif Strand) wrote:

>In article <4oi91n$3v1@seeker.the-hermes.net>,
>Geoff Weiss <geoff@seeker.the-hermes.net> wrote:
>>
>>If I remember correctly, Apple gave the reasoning why it works the way
>>it does.  What happens if you assign the same sound for startup as you
>>do for something else such as system beep.  If you remove the sound from
>>memory, you will start corrupting memory.

>The Sound Manager only reads waveforms from memory.  Careless software
>might cause the speaker to play garbage, but main memory should remain
>intact. 

>Since system sounds are stored as resources, I thought for sure that the
>system was calling ReleaseResource when it was through playing a sound. 
>That way, the sound would be purged if necessary, and cached in RAM
>otherwise.  But I noticed the same memory munching problem that Mitchell
>Spector described, so my days of happily assigning sounds to every
>possible event are over. 

>I can see where calling ReleaseResource for system sounds might be an
>awkward programming problem, since the playing of sounds is asynchronous. 
>You'd have to be careful not to release a sound before it was finished
>playing.  At the same time, you wouldn't want to wait for a given sound to
>finish before returning from SysBeep, just so you could call
>ReleaseResource. 

I have wanted to fix this problem for a long time.  I only have 2 MB
in my IIgs and I can't afford to have my memory being used by system
sounds.  That is why I only have one or two sounds asigned at present.

I always figured it would be quite simple to fix.  When you request a
sound to be played, the program that takes that request and actually
plays the sound should load the sound and start playing it and when
the interrupt to tell you that the sound has finished playing occurs,
the program should then remove the sound from memory.

I had never thought about the fact that more than one sound event
could occur with the same sound, but you should be able to get around
that by incrementing and decrementing for a particular sound to make
sure that you don't remove it until all occurences of that sound have
finished playing.  Mind you, you would need to be able to
differentiate between end of sound interrupts to be sure you
decremented the right counter.  I'm pretty sure you can do this, I'm
going purely from memory at the moment.

Anyways, this is something I would really like to see and I doubt I'll
have time to even think about it for a while.