| Re: [AD] Audio addon API / Re: Renaming of functions in kcm_audio addon |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] Audio addon API / Re: Renaming of functions in kcm_audio addon
- From: Evert Glebbeek <eglebbk@xxxxxxxxxx>
- Date: Sun, 30 Nov 2008 21:00:47 -0500
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...
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?
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.
Evert