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@ofb.net 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=3c199a0d199f0fae...
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