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.
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
