* [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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ 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; 16+ 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] 16+ messages in thread
* Re: [alsa-devel] parameter for pulse device? 2019-09-20 7:35 ` Tanu Kaskinen @ 2019-09-20 7:44 ` Takashi Iwai 2019-10-15 15:52 ` frederik 0 siblings, 1 reply; 16+ 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 related [flat|nested] 16+ messages in thread
* Re: [alsa-devel] parameter for pulse device? 2019-09-20 7:44 ` Takashi Iwai @ 2019-10-15 15:52 ` frederik 2019-10-18 6:17 ` Takashi Iwai 0 siblings, 1 reply; 16+ messages in thread From: frederik @ 2019-10-15 15:52 UTC (permalink / raw) To: Takashi Iwai; +Cc: Tanu Kaskinen, alsa-devel Dear Takashi, I tested your patch, after commenting some lines in my ~/.asoundrc, and I can confirm that it works. I can now specify a pulse device to 'ecasound': ecasound -o alsa,pulse:music -i song.wav and when I do it with no "DEVICE" argument, then it outputs to the sink defined by "pacmd set-default-sink": ecasound -o alsa,pulse -i song.wav I guess this only exercises one of the cases in your patch where the empty string is recognized as NULL: + } else if (!*device) { + device = NULL; Let me know if you want me to do more testing, and apologies for the long delay in my reply. Thanks, Frederick On Fri, Sep 20, 2019 at 09:44:19AM +0200, Takashi Iwai wrote: >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] 16+ messages in thread
* Re: [alsa-devel] parameter for pulse device? 2019-10-15 15:52 ` frederik @ 2019-10-18 6:17 ` Takashi Iwai 2019-10-18 6:41 ` frederik 0 siblings, 1 reply; 16+ messages in thread From: Takashi Iwai @ 2019-10-18 6:17 UTC (permalink / raw) To: frederik; +Cc: Tanu Kaskinen, alsa-devel On Tue, 15 Oct 2019 17:52:02 +0200, frederik@ofb.net wrote: > > Dear Takashi, > > I tested your patch, after commenting some lines in my ~/.asoundrc, and I can confirm that it works. I can now specify a pulse device to 'ecasound': > > ecasound -o alsa,pulse:music -i song.wav > > and when I do it with no "DEVICE" argument, then it outputs to the sink defined by "pacmd set-default-sink": > > ecasound -o alsa,pulse -i song.wav > > I guess this only exercises one of the cases in your patch where the empty string is recognized as NULL: > > + } else if (!*device) { > + device = NULL; > > Let me know if you want me to do more testing, and apologies for the long delay in my reply. OK, good to hear. Now I applied the patch to git repo. 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] 16+ messages in thread
* Re: [alsa-devel] parameter for pulse device? 2019-10-18 6:17 ` Takashi Iwai @ 2019-10-18 6:41 ` frederik 0 siblings, 0 replies; 16+ messages in thread From: frederik @ 2019-10-18 6:41 UTC (permalink / raw) To: Takashi Iwai; +Cc: Tanu Kaskinen, alsa-devel >OK, good to hear. Now I applied the patch to git repo. Thank you! _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 16+ 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 2019-11-15 23:28 ` [alsa-devel] Number of PCM instance (pcm device file) for one sound card xinhui zhou 1 sibling, 2 replies; 16+ 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] 16+ 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 2019-11-15 23:28 ` [alsa-devel] Number of PCM instance (pcm device file) for one sound card xinhui zhou 1 sibling, 0 replies; 16+ 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] 16+ messages in thread
* [alsa-devel] Number of PCM instance (pcm device file) for one sound card 2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou 2019-09-15 9:33 ` Takashi Iwai @ 2019-11-15 23:28 ` xinhui zhou 1 sibling, 0 replies; 16+ messages in thread From: xinhui zhou @ 2019-11-15 23:28 UTC (permalink / raw) To: alsa-devel; +Cc: alsa-user Dear all , The tutorial below states that ""Each card device can have up to four pcm instances" https://www.kernel.org/doc/html/v4.19/sound/kernel-api/writing-an-alsa-driver.html#pcm-interface <https://www.google.com/url?q=https://www.kernel.org/doc/html/v4.19/sound/kernel-api/writing-an-alsa-driver.html%23pcm-interface&sa=D&source=hangouts&ust=1573928998988000&usg=AFQjCNGmZgiENmLej2aBTQvp-tspn3u8sg> I am getting confused with the number '4' . I thought we can add 8 pcm device files by default. By setting 'CONFIG_SND_DYNAMIC_MINORS=y' , we can have more than 8 pcm device files. Does that tutorial mean only 4 pcm devices running at the same time ? 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] 16+ messages in thread
end of thread, other threads:[~2019-11-15 23:29 UTC | newest] Thread overview: 16+ 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-10-15 15:52 ` frederik 2019-10-18 6:17 ` Takashi Iwai 2019-10-18 6:41 ` frederik 2019-09-12 15:42 ` [alsa-devel] How to check ALSA version in Linux kernel xinhui zhou 2019-09-15 9:33 ` Takashi Iwai 2019-11-15 23:28 ` [alsa-devel] Number of PCM instance (pcm device file) for one sound card xinhui zhou
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).