At Wed, 07 Jan 2004 16:47:53 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> >
> >
> > if i understand the code correctly, for defining a pcmp or pcmc as a
> > slave pcm, such as,
> >
> > pcm.foo {
> > type plug
> > slave {
> > pcmp bar_playback
> > pcmc bar_capture
> > }
> > }
> >
> > snd_pcm_slave_conf() needs to know which one to be used, so that the
> > config subtree (of either pcmp, pcmc or pcm) is passed to
> > snd_pcm_open_slave().
> >
> > otherwise, you have to define slave pcms always separetly, such as,
> >
> > pcm.foo {
> > type plug
> > slave {
> > pcm bar
> > }
> > }
> > pcmp.bar bar_playback
> > pcmc.bar bar_capture
> >
> > i think it's a big restriction.
>
> As a matter of personal preference I very much prefer this latter form
i do, too.
> (as it leave capture and playback definition clearly separated as
> directions are in ALSA API).
hmm, the first example is also enough clear, i feel :)
> Under an "objective" point of view: would you really derive from the
> comparison of the two equivalent alternative syntaxes the feeling of "a
> big restriction"?
well, i admit "big" is a too big word.
but it means that the inline definition isn't equivalent any longer
with the external definition, since you cannot express the
playback/capture-only pcm in the inline slave pcm. that's what i'm
concerned.
> Technically they're quite the same.
also my asym plugin, too :) it doesn't introduce any overhead except
for parsing.
Takashi
-------------------------------------------------------
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
