[AD] Sound system

[Chris <kcat@xxxxxxxxxx>]

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