Re: rate-enumeration extention

> I want to know what bitrates are acceptable for buffers without OpenAL having to convert it, that is, what can the hardware support? Users of audio programs such as software synthesizers are accustomed to being able to tune latency, bitrate, bit depth, etc. So, in general the problems I have with OpenAL have to do with it not giving me low-level control over sound card settings. 
>   
Thanks for the feedback.  

In general, there is a "native" rate for all the implementations (either 
22050 Hz or 44100 Hz for software mixers normally, and typically 48000 
or 96000 Hz for hardware mixers), and the most efficient use of the 
implementation will be at that rate. 

Things are complicated by hardware mixing, however, because from the 
application's perspective there is probably no hit at all from using 
arbitrary sample rates (depending on the card).  For instance, on a 
modern Creative card (Audigy on up), you get 8-point interpolated 
resampling and mixing for all sources on the card itself, so there isn't 
any hit on the application's side.  This comment doesn't invalidate 
anything about what you say, however -- it could be that such an 
implementation would just list all available bitrates as "native."
On the other hand, if your application initializes a software mixer to a 
specific rate (or just retrieves the default rate from the context), 
then perhaps the application has all the information it needs -- it 
knows that buffers at that rate will probably be most efficient, and 
even divisions of that rate will also be pretty efficient due to the 
easy math.
> You mean optimizations that openal performs? Should I just ensure that said 
> features (distance model, doppler shift, etc) are turned off? I might consider 
> letting the user turn them back on as that would sound cool and some people do 
> have sufficiently fast computers or the right hardware so that it won't be a 
> problem.
>   
Yes, I mean optimizations that OpenAL performs.  In general, sticking to 
the defaults on global settings will lead to the best performance.  Due 
to the variety of implementations, however, for every feature I can 
think of which has an impact on one implementation, I can think of other 
implementations where it has no impact at all, so there isn't any way to 
be definitive on this...
Garin