[Freeciv-Dev] Re: [Patch] Sound8

[Jason Short <vze2zq63@xxxxxxxxxxx>]

Per I. Mathisen wrote:
> On Tue, 12 Feb 2002, Jason Short wrote:
>
> > Unfortunately, the code never actually resets the elements when the
> > sound sample it corresponds to is freed, so once the buffer is full this
> > will happen every time a sample is played.
> I don't understand what you are referring to.
>
>
> > Assuming ESD doesn't have a "maximum channels" limit, one solution would
> > be to just start the sample and not track it at all thereafter.  Then it
> > can end at its own time...the problem being that on shutodwn() there is
> > no way for us to stop it.  Obviously the music sample ID must be
> > tracked, since only one music should be playing at a time - but with
> > music we can be pretty sure that it won't stop until we tell it to.
> This is not a problem. Since we track music in a separate "channel"
> anyway, and only one music can play at a time, we can stop it at program
> exit separatedly of what is done to sound effects. Since the other sound
> smaples don't loop, they will stop when they are done, irrespective of
> whether the program has quit or not (unlike with SDL, where sound will
> terminate at program exit).
Ahh, this makes things clearer.  esd_sample_free destroys the cached 
data - so it is safe to call esd_sample_free on a sample, even after it 
has stopped playing.
What happens if we call esd_sample_free on a sample that is still 
playing?  Will it continue to run?  Such a thing is unlikely but 
possible, in the event that all of our "sound channels" get used up 
before a sample finishes.
Eventually, some comments explaining this process would be good.

> So we did I use sample buffering and not just a play&forget function?
> Because I wanted to add some cacheing to reduce file loads. As of now it
> only does a single cacheing check, but this could be much improved. It
> isn't any better simply because I forgot all about it once I had the basic
> structure in place and I started coding the more fun parts...
>
> Of course, if there are actual structural problems with the way the ESD
> code is written now, I'll rewrite it. I just don't see the problem with
> it as it is now.
Well, it's modular and concice enough that it can easily be rewritten or 
improved later.
> > And SDL has similar (though not identical) problems...
> Please explain.
The music channel is tracked separately.  But, it's also held somewhere 
within the audio_sdl_wave[] array.  So it is conceivable that a regular 
sample, when Mix_PlayChannel is called, could overwrite it.  Hopefully 
this is not possible (?), but if we're not sure it might be a good idea 
to add an assertion to verify it.
Also, we don't know what happens if we play more than MIX_CHANNELS 
sounds at the same time.  If this were to happen then most likely either 
(1) we'll get -1 or something from Mix_PlayChannel or (2) 
Mix_PlayChannel will replace a previously-used channel with the new 
sample.  Either way, we should check for it - although it's probably not 
a problem since MIX_CHANNELS is probably really big (?).
-----

I recommend applying the patch.  These are small problems that will not 
come up during normal play (if at all), and can easily be fixed later.
jason