Re: [AD] Sound system

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


I think we should wait for 4.2 before removing the DX mixer. That's a change that affects quite a lot of users, so this should definitely be done in a WIP. We need to make sure all the details are ironed out.


Chris wrote:
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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/