At Wed, 07 Jan 2004 17:58:10 +0100,
Abramo Bagnara wrote:
>
> Takashi Iwai wrote:
> >>>
> >>> 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.
> >
> > 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.
>
> This is true only inside duplex PCM definition and I like to consider
> that a feature, i.e. duplex definition should be the same for both
> directions.
>
> >>Technically they're quite the same.
> >
> >
> > also my asym plugin, too :) it doesn't introduce any overhead except
> > for parsing.
>
> It's true but I'd prefer to not have too many PCM types.
well, apparently it became now the argument of tastes.
technically they are almost identical.
time for vote?
> Take also in account that the association between playback stream and
> capture stream is definitely arbitrary and a well written duplex ALSA
> native application should ask for two PCM names.
the problem appears also when you want to define a generic pcm name,
such as iec958. for example, iec1712 has different number of channels
for playback and capture directions (capture has the digital mix
channels), and thus the definition of iec958 must be different between
playback and capture. in the current code, it's not allowed.
because the definition of iec958 is valid only for playback, so far,
you cannot record the spdif on ice1712 like
% arecord -Diec958 foo.wav
similarly, it would be nice to have such a feature (duplexing) if you
want override the "default" pcm together with dmix and dsnoop.
> I fear that this extension will encourage bad programming practice.
understood. we should stress this in the documents.
> Thinking further, I've changed my mind: what about to have an OSS
> emulation specific configuration?
>
> Just like:
>
> aoss_pcm_w.dsp0 dmix
> aoss_pcm_r.dsp0 dsnoop
oh yeah, that's similar with my first patch ;)
> I think it's a far better solution and will leave native library intact.
but it's also true that there is definitely a merit (even fix) by
having duplex feature like above.
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
