On Tue, Dec 6, 2011 at 6:46 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: > On Tue, Dec 06, 2011 at 06:27:23PM -0500, Paul Davis wrote: >> On Tue, Dec 6, 2011 at 5:43 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: >> >> > So, are you telling us that ALSA inserts the plugin in both >> > the capture and playback paths ? That would be absolutely >> > braindead. >> >> doesn't work that way at all. >> >> the app opens "plughw:ladspa" (for example) for playback. presto: the >> ladspa plugin is applied to the playback stream. >> the app opens "hw:0" (for example) for capture. no plugin processing >> on the capture stream. >> the app opens "plughw:ladspa" (for example) for capture. presto: the >> ladspa plugin is applied to the capture stream. > > And what if the app opens the device for capture and playback ? it will open two streams, and the processing on each one depends on the device name it uses to open each stream. > Isn't the whole 'plug' system meant to be transparent to apps, > so an app can just use 'default' and get whatever the user > configured to be 'default' ? yes, that works too. but most users (and your example) don't define "default". > Very well, but the .asoundrc syntax seems to be in terms of > duplex devices. How would you configure a plugin in 'default's > capture stream only ? the capture stream only exists when a process opens the device for capture. it is not a separate property or entity. the properties of the stream depend on the name of the device. > Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl. so does this quote predate kraftwerk or are you finally embracing the frozen four? :) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
