Re: [AD] Audio addon API / Re: Renaming of functions in kcm_audio addon

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2008-11-30, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 30-Nov-08, at 8:43 PM, Peter Wang wrote:
> > On 2008-11-30, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> >> Right. Hadn't thought of that, or rather, I hadn't considered that
> >> that wouldn't be possible. That is a bit of a pain. Actually, how  
> >> does
> >> one play multiple instances of the sample at a time through A5's API?
> >
> > Create multiple ALLEGRO_SAMPLEs, pointing to the same
> > ALLEGRO_SAMPLE_DATA.
> 
> Hmm. I did think of that, but it seemed rather silly: if you're  
> fireing off bullets in a loop it's a bit painful to have to create a  
> new sample for each and every single bullet you play (but naturally,  
> you're doing something wrong if you're starting hundreds of bullet  
> sounds in one loop). I figured there had to be a "better" way...

You can create ALLEGRO_SAMPLEs ahead of time.

Actually, that might be a better way to go for these "detachable"
samples, too.  Create a number of them ahead of time.  When one finishes
playing, instead of destroying it, automatically set its data pointer to
point to NULL to indicate it can be used for a later sound effect.

> > I have an incomplete implementation which works like this.  While
> > mixing, if the end of a sample is reached and that sample is marked
> > detachable, then that sample is put on an list of samples to destroy.
> > Each driver's update loop makes a single additional function call,  
> > which
> > will actually destroy the samples placed on the list.  Obviously, we
> > could call it rather infrequently if we like.
> 
> Ok. That sounds good, and if you already have it working it's fine.
> 
> > I only implemented it for samples attached to a mixer, i.e. not
> > samples attached to voice.  That might require more code in each  
> > driver.
> 
> I keep losing track of mixers/voices/samples while going through the  
> audio plugin so I can't oversee how much extra work that would be. As  
> a simple case though, can't we just require that detacheable samples  
> always be played through a mixer?

Yes.

> > One thread per sample? :-P
> 
> Only while it's playing, but yeah, as I said. Not the best.
> 
> > I assumed that if you needed that level of control you wouldn't use
> > detachable samples.
> 
> Maybe not; the scenario I had in mind actually had to do with making  
> sure a sample (in this case, a sample_data object) isn't being played  
> when you destroy it (or to stop the playback). Then again, I guess  
> there's no way of doing that with sample data played through the  
> "full" API either.

Hmm, yes, that is a problem.  Maybe we should have a function to force
all playing samples to stop.  And/or use the recycling idea above
instead of destroying ALLEGRO_SAMPLEs.

Peter