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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
