[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2008-04-28, Ryan Dickie <goalieca@xxxxxxxxxx> wrote:
> On Mon, Apr 28, 2008 at 4:42 AM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>
> > On 2008-04-28, Ryan Dickie <goalieca@xxxxxxxxxx> wrote:
> > >
> > > Hmm, sorry. I guess I got a bit carried away trying to refactor in order
> > to
> > > make things more manageable.
> > >
> > > I was on #allegro-dev and I found out the 'mixer' was meant to be more
> > of a
> > > 'filter' system where people could do fancy audio effects processing. I
> > > could add something like what i describe below.
> >
> > Actually, there is a much simpler purpose: we need to be able to support
> > sound
> > cards/drivers which don't support multiple voices and we need to be able
> > to
> > work with samples/streams with differing same sampling rates or formats.
> > AFAICS all that code is gone and I guess you rely on OpenAL to handle
> > that.
> > But OpenAL won't be the only backend.
> >
>
> Yes, I rely on OpenAL for this. From what I can gather, ALSA, pulseAudio,
> CoreAudio, DirectSound, and the Vista/Xbox api all handle this as well.
>
> If we do need it, then the correct place to put the mixer code would be in
> the driver and not part of the user framework. The mixing should happen
> transparently and not require the user to manage it.
But since the code is there (or would be there) anyway, we might as well
allow the user to use it in some preprocessing stages. I agree that it
should be transparent for the common case where you just want to play
some sounds.
ALSA dmix is not necessarily enabled, and OSS never had such a thing
(and we need that to support the *BSDs, I think) so as a practical
matter we need a mixer anyway. It's not particularly complicated code,
is it?
Peter