On Fri, 23 Nov 2001, Paul Davis wrote:
> >Note that my discussion is not against simpler API. The benefits are
> >visible, but that JACK solves something in the speed issues.
> >
> >Note, that it is not problem to force (using configuration) and optimize
> >ALSA plugins for one set of parameters and do requested conversions in the
> >final point (plugins). So that the applications can be written in very
> >simple way (requesting exactly required set of parameters).
>
> this is the whole problem: we don't want any parameters at all!
>
> look at the way the plugin system is working right now: we have a
> library of useful rate/format conversion code hidden inside
> alsa-lib. rather than allow programmers to use this directly on their
> data (as several have said would be very useful), it all has to be
>
> implicit and controlled via a configuration file written in an
> entirely new "small language". each time people have tried to do this
> to accomplish anything other than the most naive kind of conversions,
> it has turned out that the system needs more work to support it. there
> is no programmatic way to say, for example, "hmm, this audio file i
> want to play is at 44.1kHz, but we're running at 48kHz, so please
> insert the following plugin in my processing chain so that it sounds
> right". thats what most people typically mean by a "plugin"
> system. what alsa offers us right now is a very flexible, but static
> configuration system without the possibility of programmatic control.
>
> if i want to connect alsaplayer to a running "arbiter" that is
> controlling my audio interface, and for whatever reason that interface
> is running at 48kHz, but the file alsaplayer is told to play is not,
> this requires *dynamic* configuration of the "plugin" processing
> pathway. i don't see this in alsa-lib right now.
>
> i'm not arguing that anyone should be changing that. i'd much rather
> see alsa-lib provide a useful API for handling rate/format conversions
> since in a callback system, these are just as necessary as in any
> other system. a library of functions for rate adjustment, format
> conversion, time stretching, dither and so forth would be more useful
> for more people than devising some kind of automatic dynamic "plugin"
> reconfiguration system.
You are speaking about higher abstraction level on the one hand and on
the other, you want to control everything. But okay, I see the potential.
After some thinking, I decided that the best method to pass the parameters
to the plugin system is the current configuration syntax. It will allow us
to easy extend the current functions with no implementation cost.
You may see the snd_pcm_open_lconf function allowing to pass own
configuration at run-time. Also, we plan to extend the current API with
some form of run-time parameters, because many plugin parameters or
characteristic can be controlled at run-time.
> > I personally
> >think, that all issues are already prepared in the current very flexible
> >and extensible ALSA PCM API as well.
>
> you and abramo have built an incredibly flexible and extensible API,
> and its a great piece of work. i just happen to feel (very strongly)
> that its the wrong API for 90% of audio programmers to be using
> (because their software doesn't care about the vast majority of the
> concepts in the ALSA API).
>
> the analog would be to the macos/windows worlds, where the majority of
> audio programmers are writing plugins (VST/DirectX/MAS/RTAS/whatever)
> and have little or not interaction with the equivalent to a "PCM
> device". i think its silly to try to extend ALSA's role as a really
> great HAL into the kind of abstract audio API that callback-based
> systems represent.
We can easily offer the simple callback plugin system also in alsa-lib.
I'll integrate LADSPA to our plugin system ASAP to make an example.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
SuSE Linux http://www.suse.com
ALSA Project http://www.alsa-project.org
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
