From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: DMIX and capture stream Date: Wed, 07 Jan 2004 14:45:12 +0100 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200401051741.i05HfCXl007120@dhin.linuxaudiosystems.com> <20040106223828.39d2c233.mista.tapas@gmx.net> <3FFBFF51.1030002@tin.it> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <3FFBFF51.1030002@tin.it> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Abramo Bagnara Cc: Florian Schmidt , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Wed, 07 Jan 2004 13:45:05 +0100, Abramo Bagnara wrote: > > Takashi Iwai wrote: > > > as written in my previous mail, it was a quick hack. and there is a > > better approach. > > I'd prefer the following approach: > > pcmp.duplex { > type dmix > ... > } > > pcmc.duplex { > type dsnoop > ... > } > > with the following policy: > - if capture is specified pcmc and pcm are searched in this order > - if playback is specified pcmp and pcm are searched in this order this was my first idea, too. but i'm afraid that it will lead to more conditionals (i.e. more codes) over all plugins with a slave pcm, and make the syntax more complicated. > This would solve also the annoying problem of pcm that are valid only > for one direction and should not be used (or browsed) for the other. it's also possible by defining only playback or capture pcm.playbackonly { type asym playback.pcm foo } then the rest stream will remain undefined. Takashi ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click