[alsa-devel] parameter for pulse device?

[frederik at ofb.net]

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 at 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=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
>