Is al_create_voice() supposed to fail if you pass unsupported (by the hardware) parameters? I've found that to be the case when attempting to create, e.g. 96000Hz/24bit voices on systems where that isn't supported. The documentation for the function is vague, but it seems to imply the values can be modified under the hood ("it may be the native format of the sound hardware"), so in that case I would expect most requests to succeed even if they have to create a lower-quality voice.

I'd prefer it to fail for unsupported formats (and adjust the documentation accordingly).

As for voices in general, I think everything would become better if we added an internal mixer for each voice (alternatively, adding an optional voice for each mixer, the implementation strategy is irrelevant), making it acceptable to pass voices to al_*_mixer functions (as first parameter only) and deprecating the al_*_voice functions (just making them forward to al_*_mixer functions).

Interesting. For minisphere's Audialis API, I actually abstracted away the distinction--the Mixer object encapsulates both a mixer and voice. The voice/mixer dichotomy confused the hell out of me for the longest time, and until very recently I just stuck to using the default mixer.

The only thing that concerns me if voices and mixers are combined, is that you won't be able to create, e.g. float mixers if the driver in use doesn't support them. This issue actually bit me with the feature mentioned above. DSound doesn't allow float voices, and Allegro balks if you try to create an 8-bit mixer (for good reason!). In order to support these, I had to create the voice and mixer with different parameters. So on reflection, the distinction does have its benefits.