[Openal-devel] Some questions....

[Manuel Jander]

Hi again

On Tue, 2004-01-06 at 02:15, Joe Tennies wrote:
> okay.  maybe I'm misunderstanding.  Are you talking having the WHOLE
> backend fallback or just have a couple sources fallback?  The last
> discussion ended that all software sources is good, all hardware sources
> is good, use hardware sources until you run out and then software
> sources == bad.

OK. I understood. But why is "all hardware sources is good, use hardware
sources until you run out and then software" so bad at all ? I think
that precisely that should be the most desirable behavior.

For example the now dead A3D API includes a resource manager for
handling this. So the sources that really need spatialization, they get
it in hardware. Other things like ambient sounds and the like get other
normal DMA channels. Only if the preset maximal software sources value
is crossed, the next sources get "virtual" (no hardware nor software
handles them). As soon as a new source is available, the most highest
priority "virtual source" takes it place.

Best Regards


> On Mon, 2004-01-05 at 18:09, Manuel Jander wrote:
> > Hi,
> > 
> > On Mon, 2004-01-05 at 12:40, 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.
> > 
> > Well that is really odd, since the current MAC and Linux ports do
> > anything in software. If software rendering is not available in OpenAL
> > as a mean of fallback, that means that every single audio backend should
> > handle fallbacks by itself. Wouldn't it easier to provide that inside of
> > OpenAL itself ? I need to know that because if i don't get this right
> > i'm designing/coding nonsense :)
> > 
> > Thanks
> > 
> > 
> > > 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