Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2002:
[Freeciv-Dev] Re: [Patch] Sound8
Home

[Freeciv-Dev] Re: [Patch] Sound8

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv-Dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [Patch] Sound8
From: "Per I. Mathisen" <Per.Inge.Mathisen@xxxxxxxxxxx>
Date: Wed, 13 Feb 2002 00:08:56 +0100 (MET)

On Tue, 12 Feb 2002, Jason Short wrote:
> Raimar Falke wrote:
> > I have spent the previous days working on the sound patch. The newest
> > version 8 is now in the incoming (too large for the list). Changes
> > since version 7 include:
> >  - reworked audio* to allow a real plugin mechanism without special
> >  cases and #ifdefs (this also allows to change the plugin at runtime
> >  just one call to audio_select_plugin())
> >  - extend README.sound
> >  - add sounds for all improvements (formerly only wonders)
> >  - add alternative fight and move tags
> >  - rename the event tags to be consistent (at least a bit)
> >  - add a mechanism to map "normal" events to sound events
> >  - sound is now always be enabled
> >  - a lot of other small changes

Thanks for going over the patch, Raimar. I havent looked at it yet for
obvious reasons.

> > TODO:
> >  - adjust civ2sounds.spec to use the new names (I don't have a civ2 cd
> >  handy for this)

civ2sounds.spec should perhaps not be included in the distro? maybe better
as a download.

> In audio_esd.c: I am confused.  Why do we need to have a limited number
> of samples?  Is this just to make shutdown() easier?

All this from foggy memory, but the reason is we need to free samples
after a while, or memory can start to fill up rather fast with lots of
them (if they are big and you dont have lots of memory). I think. Never
actually done the maths and checked if this is a real problem, just
assumed using minimal amount of memory is a good thing. But maybe thats
what virtual memory is for.

>  Once a sample is
> started, what happens when it ends?

It waits for the sample slot to be reused.

>  It looks like the sample_id value
> just sits around until the loop comes back, and then it will be manually
> "killed" (esd_sample_free), even though it has most likely already
> finished playing.

Ten sounds will be played between a sample_id slot is first used and the
second time, and if it hasnt managed to stop by itself, it will be
destroyed in the name of sound clairity or something (we dont want ten
soudns at the same time, I think).

>  Finally, the circular buffer used for tracking sample
> numbers will only work correctly if all samples are of the same length;
> if there was one very long sample a number of shorter ones could cycle
> through while it was playing...and later we could end up killing it even
> if it was the only sample currently playing.

We could try to see if there was another sample slot open instead of
killing it immediately, but ... the issue is mostly theoretical I think.

> In audio_sdl.c: here there is a similar situation.  SDL tells us to use
> no more than MIX_CHANNELS different channels, so here it may be
> necessary to do something clever.  But it looks like things are a bit
> broken - music is supposed to go on its own channel, but this isn't
> enforced so it looks like a regular sound could overwrite it.

No, that shouldnt be possible. I am pretty sure I thought of that.

Yours,
Per

"What we anticipate seldom occurs: but what we least expect generally
happens." -- Benjamin Disraeli




[Prev in Thread] Current Thread [Next in Thread]