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 26-Nov-08, at 10:55 PM, Peter Wang wrote:
> > On 2008-11-26, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> >> 1. Rename al_load_sample -> al_load_sample_data()
> >
> > Ok.
> 
> Done.
> 
> > I'm not sure it's quite right.  Most games like to play multiple
> > instances of the same sample data simultaneously, e.g. gun shots.
> 
> 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.

> You cannot attach the same ALLEGRO_SAMPLE to more than one mixer at a  
> time and calling al_play_sample() again seems to reset the voice to  
> the beginning of the sample rather than play a new instance of it  
> (from looking at the code, I haven't actually tried this yet).
> 
> > 2. Have a function that creates and plays an ALLEGRO_SAMPLE from an
> > ALLEGRO_SAMPLE_DATA, attaching it to the default mixer.
> 
> al_play_sample_data(ALLEGRO_SAMPLE_DATA*)?
> 
> > 3. Allow ALLEGRO_SAMPLEs to be "detachable", i.e. automatically
> > destroy themselves when finished playing.  Only non-looping samples  
> > can
> > be detached.  Maybe the function for (2) should always create detached
> > samples.
> 
> One minor problem with this: the sample would need to be destroyed by  
> the function that monitors playing samples, but that's specific to  
> each driver. In other words, every driver would have to check whether  
> the sample has to be destroyed and do that when necessary. It  
> shouldn't be necessary to do that on the level of each driver. The  
> pain can be eased somewhat by making a function  
> "_al_destroy_detachable_sample()", but it's still a bit ugly.

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.

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.

> Instead, maybe al_play_sample_data() should create a new thread where  
> a new sample is created from the sample data, the sample is played  
> (the thread rests until it is done playing) and then destroyed. It's a  
> bit hackish though.

One thread per sample? :-P

> One snag: with such a system, how would one check whether the sound is  
> still playing? You can't query an ALLEGRO_SAMPLE_DATA object and the  
> ALLEGRO_SAMPLE is hidden from the user.

I assumed that if you needed that level of control you wouldn't use
detachable samples.

Peter