Re: [AD] Some sound driver questions

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2007-06-12 at 21:21 +0100, Colin Ward wrote:
> Hello all.
> 
> I have just implemented the sound driver for the Amiga port of Allegro and I
> have a couple of questions.
> 
> Firstly, in the DIGI_DRIVER structure we have voices, max_voices and
> def_voices.  How do these differ in use?  I have currently set all three to
> 8 (which is a reasonable number for modern Amiga sound hardware, but really
> just an arbitrary choice).  Also what is the basevoice member?  Currently I
> simply leave this at zero.

I don't know, but some drivers simply use allegro's software mixer
instead. In fact, I guess besides one of the windows drivers, yours is
the only one to try and implement the hardware mixing functions.

> Secondly, a question regarding the functions that are called to play a
> sample.  When I play a sample I notice that the following functions in my
> sound driver are called (in this order IIRC):
> 
> init_voice() => Load the sample into the Amiga audio API
> start_voice() => Start playback of the sample loaded by init_voice()
> 
> Sample plays, and upon stopping:
> 
> release_voice() => ???
> stop_voice() => I stop playback and free the sample
> 
> Two questions: 1) What am I supposed to do in release_voice()?  2) If
> stop_voice() is called, can start_voice() be called again *without*
> init_voice() being first called?  If that is the case then I guess
> stop_voice() should stop playback but not free the sample.

I think it is like that. E.g. from the software mixer (src/mixer.c):

void _mixer_stop_voice(int voice)
{
   mixer_voice[voice].playing = FALSE;
}

I didn't actually check this is the correct vtable entry, but looks like
it.

> Also, if the sample being loaded from a .wav file is an 8 bit sample then I
> noticed that it is 8 bit unsigned.  The Amiga audio API doesn't support
> this (it only supports signed samples, either 8 or 16 bit) so in
> init_voice() I have to allocate a buffer and convert from 8 bit unsigned =>
> 8 bit signed.  This isn't nice because it means a memory allocation every
> time that sample is played and because it is slow, not to mention that if a
> sample is loaded once and then played multiple times then it has to be done
> every time.  It would be better to convert it when it is being loaded by
> src/sound.c/load_wav_pf().  If I wanted to add this feature as an
> improvement to Allegro (with the aim of having it committed to Subversion,
> maybe configured with a #define), what would be the best way of going about
> it?

The problem is programs accessing the sample data directly, or using
audio streams. For Allegro 5.0, this definitely should be addressed, so
we allow all the common formats (as we do with pixel formats now). Not
sure what KittyCat's API or mimix's ALSA implementation of that do.

For 4.2/4.4, I'm not sure what can be done. At least in the case of
audio streams, we would have to find a way to still accept unsigned
data, as that's what addons like e.g. DUMB are likely expecting.

> Thanks in advance for any advice.
> 

Well, I know not much about this, let's see if the sound persons can say
more.

-- 
Elias Pschernig <elias@xxxxxxxxxx>