Thank you for the tips.
I don't know if my input is still needed, but I figured out from looking at some of the syntax you linked to that I can put this in ~/.asoundrc and it does the job (this is what I had had in mind when I asked about "magic with macros", it is somewhat advanced for me):
pcm.!pulse {
@args [ DEV ]
@args.DEV {
type string
default "default"
}
type pulse;
device $DEV
}
Now I can set up a filter like this:
ecasound -i alsa,pulse:mic -o alsa,pulse:monitor
Is something like this going into the alsa-plugins repo?
Thanks,
Frederick
On Tue, Sep 17, 2019 at 03:17:49PM +0200, Takashi Iwai wrote:
On Tue, 17 Sep 2019 15:14:53 +0200,
Tanu Kaskinen wrote:
On Tue, 2019-09-17 at 14:55 +0200, Takashi Iwai wrote:
> On Tue, 17 Sep 2019 14:51:01 +0200,
> Tanu Kaskinen wrote:
> > On Tue, 2019-09-10 at 10:33 -0700, frederik@xxxxxxx wrote:
> > > On Mon, Sep 09, 2019 at 07:52:24PM +0200, Takashi Iwai wrote:
> > > > It depends on how pcm.pulse is defined. If it's defined to take an
> > > > argument, it can work like that. (Or sometimes you may need to pass
> > > > the argument explicitly like "pulse:{device=mointor}".)
> > > >
> > > > The standard pcm.pulse definition provided in alsa-plugins repo
> > > > doesn't take the argument, and that can be the reason.
> > >
> > > Thank you Takashi. Would it be easy to change alsa-plugins so that it
> > > takes an argument? Is there a chance that this change would be
> > > accepted?
> > >
> > > If you can point me to the section of code in e.g. "plughw" where
> > > argument parsing is done, then I would probably end up modifying
> > > alsa-plugins myself, just to simplify what I am doing.
> >
> > This commit might be instructive:
> > https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=3c199a0d199f0fae78c9c1b19c11878a6134b3a8
>
> Yes, thanks for pointing an example.
>
> Now I took a quick look at the current code, and one remaining problem
> is that there is no device parameter value corresponding to the
> default (=NULL). Maybe we should accept the string "default" to be
> treated as NULL, for example.
>
> Ditto for the server parameter.
Maybe "", i.e. the empty string, would be a good choice for the special
string representing NULL? It's not a valid device name or server
address, unlike "default", so there can't be any conflicts. Not that
"default" is very likely to cause conflicts either.
Yeah, that sounds feasible.
Then the rest is just coding ;)
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
