[Openal-devel] Software fallback.

[Openal-devel] Software fallback.

[Manuel Jander]

Hi,

I'm cross posting this from OpenAL, since it may have some relevance to
ALSA.

As some already might know, i'm designing a ALSA - OpenAL interface for
advanced hardware feature support.

As far as i understood, they say that the would prefer to handle any
kind of resource managing and moire specifically "software fallback"
functions inside of each driver. I don't know yet much about the "plug"
extensions, but i remember someone commenting that one can pass PCM data
through LADSPA plugins with this. I was thinking that maybe such a kind
of mechanism could be used to route "software fallback" PCM channels
through appropriate software filters. Could anyone with more knowledge
comment about that ?

Best Regards
 

On Wed, 2004-01-07 at 15:15, Garin Hiebert wrote:
> > 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.
> 
> I suppose this would be a good item to put into a FAQ, if we had one (note
> to self...).
> 
> The reason why hardware sources don't "rollover" to software sources is
> that the transition from one to the other would be noticable in a really
> bad way.  If you have a 7.1 speaker setup playing X sources with EAX
> support, you don't want to add one more source and find that it is only
> spatialized into the front two speakers without reverb -- that would just
> sound strange.  On top of that, all of a sudden a game's framerate would
> radically change.  You might be running along at 60 frames per second with
> hardware sources, and then suddenly the game creates five software sources
> and the framerate goes down to 45 fps because of the entirely new
> rendering path being activated.
> 
> At some point, the application should deal with voice management anyways
> -- having an un-constrained number of sources for your application will
> just lead to miserable performance for no good reason (in that there
> probably aren't 758 things you really should be listening to at the same
> time anyways even if they can all be rendered).
> 
> Garin
> 
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html