Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [alsa-devel] parameter for pulse device?
@ 2019-09-04 16:47 frederik
  2019-09-09 17:52 ` Takashi Iwai
  2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou
  0 siblings, 2 replies; 12+ messages in thread
From: frederik @ 2019-09-04 16:47 UTC (permalink / raw)
  To: alsa-devel; +Cc: alsa-user

Dear ALSA,

In my ~/.asoundrc, I have lines like this:

    pcm.mic { type pulse; device "mic" }
    pcm.monitor { type pulse; device "monitor"; }
    pcm.music { type pulse; device "music"; }

to make it easier for ALSA-aware programs to input and output via PulseAudio, e.g.:

    ecasound -i alsa,mic -o alsa,monitor -etd:...

However, I would like to simplify this and not have to update ~/.asoundrc every time I create a new PulseAudio device. Since ALSA has the ability for PCMs to take a parameter, I thought this might work with the "pulse" PCM and the PulseAudio device name. But I get an "error: Invalid argument" when trying to pass the device name as an argument to the "pulse" PCM:

    $ ecasound -o alsa,pulse:music -i some.wav
    ...
    ALSA lib conf.c:5014:(snd_config_expand) Unknown parameters music
    ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM pulse:music
    ERROR:  Connecting chainsetup failed: "Enabling chainsetup: AUDIOIO-ALSA:
    ... Unable to open ALSA-device for playback; error: Invalid argument"

Is there some magic with macros that I can use to accomplish this syntax, or can we add the ability for the "pulse" PCM to take a parameter naming the device?

Thanks,

Frederick
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-04 16:47 [alsa-devel] parameter for pulse device? frederik
@ 2019-09-09 17:52 ` Takashi Iwai
  2019-09-10 17:33   ` frederik
  2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou
  1 sibling, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2019-09-09 17:52 UTC (permalink / raw)
  To: frederik; +Cc: alsa-devel

On Wed, 04 Sep 2019 18:47:06 +0200,
frederik@ofb.net wrote:
> 
> Dear ALSA,
> 
> In my ~/.asoundrc, I have lines like this:
> 
>    pcm.mic { type pulse; device "mic" }
>    pcm.monitor { type pulse; device "monitor"; }
>    pcm.music { type pulse; device "music"; }
> 
> to make it easier for ALSA-aware programs to input and output via PulseAudio, e.g.:
> 
>    ecasound -i alsa,mic -o alsa,monitor -etd:...
> 
> However, I would like to simplify this and not have to update ~/.asoundrc every time I create a new PulseAudio device. Since ALSA has the ability for PCMs to take a parameter, I thought this might work with the "pulse" PCM and the PulseAudio device name. But I get an "error: Invalid argument" when trying to pass the device name as an argument to the "pulse" PCM:
> 
>    $ ecasound -o alsa,pulse:music -i some.wav
>    ...
>    ALSA lib conf.c:5014:(snd_config_expand) Unknown parameters music
>    ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM pulse:music
>    ERROR:  Connecting chainsetup failed: "Enabling chainsetup: AUDIOIO-ALSA:
>    ... Unable to open ALSA-device for playback; error: Invalid argument"
> 
> Is there some magic with macros that I can use to accomplish this syntax, or can we add the ability for the "pulse" PCM to take a parameter naming the device?

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.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-09 17:52 ` Takashi Iwai
@ 2019-09-10 17:33   ` frederik
  2019-09-17 12:51     ` Tanu Kaskinen
  0 siblings, 1 reply; 12+ messages in thread
From: frederik @ 2019-09-10 17:33 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: alsa-devel

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.

Thanks,

Frederick
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [alsa-devel] How to check ALSA version in Linux kernel
  2019-09-04 16:47 [alsa-devel] parameter for pulse device? frederik
  2019-09-09 17:52 ` Takashi Iwai
@ 2019-09-12 15:42 ` xinhui zhou
  2019-09-15  9:33   ` Takashi Iwai
  1 sibling, 1 reply; 12+ messages in thread
From: xinhui zhou @ 2019-09-12 15:42 UTC (permalink / raw)
  To: alsa-devel; +Cc: alsa-user

>
> Dear all,
>

      I am involved in a project which will use different kernel versions
along the way, first 4.14, 4.19, 5.3 etc.

    How can I know the differences in ALSA, besides comparing files ?
How to get the ALSA version in Linux kernel ?

  Thanks a lot,

Xinhui,
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] How to check ALSA version in Linux kernel
  2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou
@ 2019-09-15  9:33   ` Takashi Iwai
  0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2019-09-15  9:33 UTC (permalink / raw)
  To: xinhui zhou; +Cc: alsa-user, alsa-devel

On Thu, 12 Sep 2019 17:42:37 +0200,
xinhui zhou wrote:
> 
> >
> > Dear all,
> >
> 
>       I am involved in a project which will use different kernel versions
> along the way, first 4.14, 4.19, 5.3 etc.
> 
>     How can I know the differences in ALSA, besides comparing files ?
> How to get the ALSA version in Linux kernel ?

There is no "ALSA version" any longer in the kernel side.  The
protocol is kept in backward-compatible way, and a new protocol is
checked via each protocol version number ioctl.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-10 17:33   ` frederik
@ 2019-09-17 12:51     ` Tanu Kaskinen
  2019-09-17 12:55       ` Takashi Iwai
  0 siblings, 1 reply; 12+ messages in thread
From: Tanu Kaskinen @ 2019-09-17 12:51 UTC (permalink / raw)
  To: frederik; +Cc: alsa-devel

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=3c199a0d199f0fae78c9c1b19c11878a6134b3a8

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-17 12:51     ` Tanu Kaskinen
@ 2019-09-17 12:55       ` Takashi Iwai
  2019-09-17 13:14         ` Tanu Kaskinen
  0 siblings, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2019-09-17 12:55 UTC (permalink / raw)
  To: Tanu Kaskinen; +Cc: alsa-devel, frederik

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


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-17 12:55       ` Takashi Iwai
@ 2019-09-17 13:14         ` Tanu Kaskinen
  2019-09-17 13:17           ` Takashi Iwai
  0 siblings, 1 reply; 12+ messages in thread
From: Tanu Kaskinen @ 2019-09-17 13:14 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: alsa-devel, frederik

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=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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-17 13:14         ` Tanu Kaskinen
@ 2019-09-17 13:17           ` Takashi Iwai
  2019-09-19 21:12             ` frederik
  0 siblings, 1 reply; 12+ messages in thread
From: Takashi Iwai @ 2019-09-17 13:17 UTC (permalink / raw)
  To: Tanu Kaskinen; +Cc: alsa-devel, frederik

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=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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-17 13:17           ` Takashi Iwai
@ 2019-09-19 21:12             ` frederik
  2019-09-20  7:35               ` Tanu Kaskinen
  0 siblings, 1 reply; 12+ messages in thread
From: frederik @ 2019-09-19 21:12 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Tanu Kaskinen, alsa-devel

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=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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-19 21:12             ` frederik
@ 2019-09-20  7:35               ` Tanu Kaskinen
  2019-09-20  7:44                 ` Takashi Iwai
  0 siblings, 1 reply; 12+ messages in thread
From: Tanu Kaskinen @ 2019-09-20  7:35 UTC (permalink / raw)
  To: frederik, Takashi Iwai; +Cc: alsa-devel

On Thu, 2019-09-19 at 14:12 -0700, frederik@ofb.net wrote:
> 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?

I'm sure something like this will be accepted if you submit a patch. I
got the impression that Takashi isn't willing to write the patch
himself, and nor am I, so you're in the best position to make this
happen.

Note that

            default "default"

doesn't do the intended thing with the current pcm_pulse.c code. With
the current code the plugin will request PulseAudio to use a device
named "default", which most likely won't exist and playback or
recording will fail. The plugin code needs to pass NULL as the device
name to pa_stream_connect_playback() and pa_stream_connect_record()
when it detects that the default device is requested, so you'll need to
modify pcm_pulse.c in order to make this work. Instead of "default" as
the special string in the configuration, I suggested using "".

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [alsa-devel] parameter for pulse device?
  2019-09-20  7:35               ` Tanu Kaskinen
@ 2019-09-20  7:44                 ` Takashi Iwai
  0 siblings, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2019-09-20  7:44 UTC (permalink / raw)
  To: Tanu Kaskinen; +Cc: alsa-devel, frederik

On Fri, 20 Sep 2019 09:35:59 +0200,
Tanu Kaskinen wrote:
> 
> On Thu, 2019-09-19 at 14:12 -0700, frederik@ofb.net wrote:
> > 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?
> 
> I'm sure something like this will be accepted if you submit a patch. I
> got the impression that Takashi isn't willing to write the patch
> himself, and nor am I, so you're in the best position to make this
> happen.

I have a test patch but had no chance to test the stuff at all
currently as I am (and will be for the next few weeks) traveling.

> Note that
> 
>             default "default"
> 
> doesn't do the intended thing with the current pcm_pulse.c code. With
> the current code the plugin will request PulseAudio to use a device
> named "default", which most likely won't exist and playback or
> recording will fail. The plugin code needs to pass NULL as the device
> name to pa_stream_connect_playback() and pa_stream_connect_record()
> when it detects that the default device is requested, so you'll need to
> modify pcm_pulse.c in order to make this work. Instead of "default" as
> the special string in the configuration, I suggested using "".

Below is the totally untested patch (even not build-tested!)
If anyone interested, feel free to cook it.


thanks,

Takashi

---
diff --git a/pulse/50-pulseaudio.conf b/pulse/50-pulseaudio.conf
index 62da207af9ca..916258d942af 100644
--- a/pulse/50-pulseaudio.conf
+++ b/pulse/50-pulseaudio.conf
@@ -1,7 +1,13 @@
 # Add a specific named PulseAudio pcm and ctl (typically useful for testing)
 
 pcm.pulse {
+	@args [ DEVICE ]
+	@args.DEVICE {
+		type string
+		default ""
+	}
 	type pulse
+	device $DEVICE
 	hint {
 		show {
 			@func refer
diff --git a/pulse/ctl_pulse.c b/pulse/ctl_pulse.c
index fbb6eae2ec76..9b820fd04b15 100644
--- a/pulse/ctl_pulse.c
+++ b/pulse/ctl_pulse.c
@@ -664,6 +664,8 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &server) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*server) {
+				server = NULL;
 			}
 			continue;
 		}
@@ -671,6 +673,8 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &device) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*device) {
+				device = NULL;
 			}
 			continue;
 		}
@@ -678,6 +682,8 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &source) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*source) {
+				source = NULL;
 			}
 			continue;
 		}
@@ -685,6 +691,8 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &sink) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*sink) {
+				sink = NULL;
 			}
 			continue;
 		}
diff --git a/pulse/pcm_pulse.c b/pulse/pcm_pulse.c
index 283174357e8b..869c9b674c6b 100644
--- a/pulse/pcm_pulse.c
+++ b/pulse/pcm_pulse.c
@@ -1069,6 +1069,8 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &server) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*server) {
+				server = NULL;
 			}
 			continue;
 		}
@@ -1076,6 +1078,8 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &device) < 0) {
 				SNDERR("Invalid type for %s", id);
 				return -EINVAL;
+			} else if (!*device) {
+				device = NULL;
 			}
 			continue;
 		}
@@ -1091,6 +1095,8 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 			if (snd_config_get_string(n, &fallback_name) < 0) {
 				SNDERR("Invalid value for %s", id);
 				return -EINVAL;
+			} else if (!*fallback_name) {
+				fallback_name = NULL;
 			}
 			continue;
 		}
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-04 16:47 [alsa-devel] parameter for pulse device? frederik
2019-09-09 17:52 ` Takashi Iwai
2019-09-10 17:33   ` frederik
2019-09-17 12:51     ` Tanu Kaskinen
2019-09-17 12:55       ` Takashi Iwai
2019-09-17 13:14         ` Tanu Kaskinen
2019-09-17 13:17           ` Takashi Iwai
2019-09-19 21:12             ` frederik
2019-09-20  7:35               ` Tanu Kaskinen
2019-09-20  7:44                 ` Takashi Iwai
2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou
2019-09-15  9:33   ` Takashi Iwai

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org alsa-devel@archiver.kernel.org
	public-inbox-index alsa-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox