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.
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.
I fear that this extension will encourage bad programming practice.
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
I think it's a far better solution and will leave native library intact.
-- Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.0546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
------------------------------------------------------- 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
