[alsa-devel] parameter for pulse device?

[Takashi Iwai]

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