Okay, I've been talking about this recently, as well as having done some
prelim work on the mixer. Here is the current plan of what I would like
to do with Allegro's sound design. What I would hope this would
accomplish is create a more centralized mixer design, offering tighter
integration into the sound API which would reduce the amount of code
needed and thus CPU load, as well as being mixer(software)-extendable,
instead of having to rewrite all the drivers anytime something new is
added. The mixer itself would also be able to call into the drivers,
providing easier use of any hardware acceleration.
The current sound system works as such. You request a voice to play an
audio sample with. The request is passed into the audio drivers, where
it just calls into the mixer (the DX mixer is the only exception here).
This means that anytime a request is made relating to sound, the driver
must have an entry to support it. While this works, it is not that
efficient. The sound drivers need to be designed around the sound API,
even though all they really do is call into the mixer (the DX mixer
again being the only exception). This increases code size and execution
time by adding a redundant step to the drivers. Also as a result,
anytime a new sound feature is added, each and every driver needs to be
changed to support it (or else add dummy entries, which isn't always
possible).
What I would like to do is this. Change the sound API to call directly
into the mixer. The only thing stopping this from happening right now
is, of course, the DX mixer. This would make the mixer the focal point
of the sound, and thus anything that would want to be added only needs
to look here for basic support. The mixer can then be extended to work
with the audio drivers to support any driver-specific extensions
(hardware acceleration, hardware mixing, surround sound effects, ect).
Here's the basic pathways for using sound:
Initialization:
sound init->mixer init->card init
Currently the last two are backwards here. The card init step would
alert the mixer if anything requested wasn't possible (ie bad bitdepth,
frequency out of range, too many channels, ect), and just set the
closest mode possible.
Request:
sound API->mixer API->driver(?)
Again, the last two steps are currently backwards. Depending on the
request, the third step could even be skipped and just done purely in
software. What this means in terms of hardware acceleration is that
anytime something can be done in hardware, the mixer just passes it off
to the driver. If there's a second voice request and the driver supports
multiple hardware voices, it could ask the driver for another voice. If
no more voices are available, it would just tie it into the main voice
(the one made durring initialization that constantly runs) and do the
mixing in software as normal. Now, since no part of the core sound
design is skipped, it means nothing goes to waste, and adding code in
the core would effect the whole library, instead of whichever drivers
can be jerry-rigged to support it.
Now for the last part. The only thing standing in the way of these
enhancements is the DirectX mixer driver. Since the DX mixer driver is
basically a hack to attempt to support hw acceleration, it completely
misses out on future extandability, or at least makes it that much
harder. It also cuases problems for other drivers that may want to
support hw voices but can't due to the fact that the driver doesn't
support sw voices (see: ALSA, OSS, any DOS driver, WaveOut, ect). The
way things work with the DX mixer is by assuming there's either one
available hardware voice, in which case Allegro needs to do all the
mixing itself, or by assuming virtually unlimited driver-supplied
voices, regardless of it's hardware or software, and bypass Allegro
completely. There is no middle ground. My propsed changes wuold create
that middle ground and be able to support any number of driver-provided
voices, while making sure Allegro is never bypassed (which skips out on
core functionality when it is) and that there will alwys be enough
voices for the programmer to use.
These changes I can do by myself for the most part. What I'd need the
most help with, of course, is testing.
BTW, no. As mentioned before, these changes can take place durring 4.2
releases, so it won't delay that. The only thing I'd like to see before
4.2.0 is my current mixer changes, and the removal of the DX mixer
driver. Since those steps are the most drastic, I'd like to see some
testing on them before a non-WIP release. The patch I just recently
posted for wdsndmix.c should take care of the DX mixer, and as soon as I
get word on what I can do to the low quality mixer, I can provide
another patch for mixer.c.
- Kitty Cat
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click