[Openal-devel] Some questions....

[Ryan Underwood]

Why would software fallback not be available as a user-configurable
option?  After all, only the user knows whether his sound card has
enough hardware streams, and whether or not his system is powerful
enough to handle the load of streams that have spilled over into
software rendering.  This would also be application-dependent too; maybe
it is fine when running Unreal Tournament to have some software streams
because the game itself is not too taxing, but UT2003 needs all the CPU
it can get to maintain framerate.  And maybe some games try to use more
streams than others and end up in fallback more often; so let the polite
games use a software fallback, and disable it for the ones that are a
hog.

It could be configured through an environment variable or configuration
file, if OpenAL has one.  Maybe even better, provide an API to enable or
disable software fallbacks so the application programmer can provide the
option to the user directly within the game itself.  Then it can just be
provided in generic tech support FAQs: "Q: My game is running too slow!
A:  Buy a faster computer.  A: You could also try disabling 3D Audio
software fallbacks in the Settings menu."

On Mon, Jan 05, 2004 at 08:40:52AM -0800, Joe Tennies wrote:
> Actually, there has been a lot of discussion about software fallback.  
> 
> From what I recall, the general opinion was to NOT have a software
> fallback.  If you are doing HW resources and you run out of that
> resource.... you ran out.  That's it.
> 
> I may be wrong though.
> 
> On Sun, 2004-01-04 at 18:45, Manuel Jander wrote:
> > Hi,
> > 
> > I'm trying to find out the barrier between hardware dependent parts of
> > code and hardware independent parts. The idea is to outline where
> > exactly i have to work with "scissors" to lay in hardware aware backends
> > for OpenAL.
> > 
> > I have concluded some things, and i would like some feedback to know if
> > i'm right or if i'm wrong:
> > 
> > - The Windows port relays any hardware resource management to the
> > corresponding backend (hardware accel usage and software fallback
> > implementation), while the Unix (Linux and MAC) port doesn't do any
> > resource management at all.
> > It seems to me that the best would to integrate resource management into
> > OpenAL. The backend number is to large, and non of them supports
> > resource management further than stream accounting and denial of new
> > streams if no more are available. Since the resource management needs to
> > provide software fallback on resource starvation, existing means of
> > resource management are not useable.
> > 
> > - In the Linux port "void _alProcessFlags( void )" (almixer.c) does no
> > processing at all, or did i miss something ? What kind of processing is
> > it meant to do ? 
> > I would like to remark that fiddling with a buffer while it is being
> > played isn't supported by some audio driver models. Doing so can break a
> > lot of things. Once a buffer block has been "submitted" it shouldn't
> > (may be can't) be touched again. 
> > 
> > - There is no resource manager nor infrastructure that allows
> > "diverting" specific calls (in mixer, filter, etc) to hardware specific
> > calls or software callbacks. Such implementation requires some kind of
> > priorities for sources. Implementing priority requires changing OpenAL
> > down to its roots, and most probably no developer would like that. Any
> > ideas ? Could such changes be approved ?
> > 
> > Best Regards, and don't hesitate to send any comments. I need feedback !
> > 
> > 
> > _______________________________________________
> > openal-devel mailing list
> > openal-devel at opensource.creative.com
> > http://opensource.creative.com/mailman/listinfo/openal-devel
> -- 
> Joe Tennies <rotund at fatnsoft.com>
> 
> _______________________________________________
> openal-devel mailing list
> openal-devel at opensource.creative.com
> http://opensource.creative.com/mailman/listinfo/openal-devel
> 

-- 
Ryan Underwood, <nemesis at icequake.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://localhost.localdomain/pipermail/openal-devel/attachments/20040107/172a6faa/attachment.bin