Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
Lennart Poettering wrote:
> On Thu, 01.05.08 14:58, Colin Guthrie ([EMAIL PROTECTED]) wrote:
>
>> Sjoerd Simons wrote:
>>> Hi,
>>>
>>> The attached patch extends the alsa pulse plugin set with a alsa
>>> configuration hook. Allowing one to specify some configuration parameters
>>> that only come into effect when pulseaudio is running.
>>>
>>> For example a configution file like:
>>>
>>> @hooks [ {
>>>func on_pulse_is_running
>>> pcm.!default { type pulse }
>>> ctl.!default { type pulse }
>>>}
>>>]
>> Just a quick question as I've not had a chance to try this out yet!
>>
>> Does your code consider pulse as unavailable if it's suspended?
>
> Uh? Better not.
>
> PA by default suspends sinks these days when they are not used. Hence
> implementing what you requested doesn't really do any good.
I guess I meant "does it check to see if pulse can be unsuspended (e.g.
if it is in suspended state, is it possible to unsuspend)". I'm not sure
if this is possible with the API.
Col
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
On Mon, 28.04.08 09:53, Colin Guthrie ([EMAIL PROTECTED]) wrote: > > Sjoerd Simons wrote: > > The attached patch extends the alsa pulse plugin set with a alsa > > configuration hook. Allowing one to specify some configuration parameters > > that only come into effect when pulseaudio is running. > > I was waiting with baited breath after your chat on IRC as to what your > solution would actually be! > > I like it! > > I think the overhead at initialisation is probably OK, although I guess > it depends on how an application works - e.g. if it constant opens and > closes alsa connections then does this overhead mount up? If not then > this looks like a good solution. > > That said Lennart has said in the past that he didn't like the idea of > Alsa automatically falling back to h/w access if pulse isn't > responding. (this was in reference to tweaking the alsa plugin itself, > rather than this approach which is slightly different conceptually, > albeit with the same end goal). I think his comment at the time was "it > masks configuration problems". > > Do you have any thoughts on this Lennart? I think that the patch is OK although it does have some problems as Sjoerd already pointed out. My plan for the future is to enable auto-spawning by default in addition to starting PA by gnome-session. This will tape over these problems, too. The reason for this is that as it stands right now, PA doesn't really work from the console. Since console logins don't have anything like a session manager, we cannot really start PA from there. Same with SSH logins or System services using PA. Unfortunately console logins are still very important for a11y people, and audio happens to be too. So, PA will be started as user-daemon (not session daemon!) from session managers, in addition to be started by auto-spawning. This will tape over configuration problems, but heck, I see no better way. Then I will write a small module that terminates PA if a) no client is connected anymore and b) the user owning it is not logged in anymore according to CK and c) some time has passed. Then I'll add some code that PA won't terminate anymore when an X11 connection dies. And then everything is bright an shiny. That way PA will probably feel more robust to many people and we'll win the hearts of our a11y people ;-) So, in summary: I don't think Sjoerd's patch is flawless, or that it is the way to the future. But it's an OK temporary fix on our way to world domination. It get's the "Approved by Lennart" stamp. ;-) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
On Thu, 01.05.08 14:58, Colin Guthrie ([EMAIL PROTECTED]) wrote:
>
> Sjoerd Simons wrote:
> > Hi,
> >
> > The attached patch extends the alsa pulse plugin set with a alsa
> > configuration hook. Allowing one to specify some configuration parameters
> > that only come into effect when pulseaudio is running.
> >
> > For example a configution file like:
> >
> > @hooks [ {
> >func on_pulse_is_running
> > pcm.!default { type pulse }
> > ctl.!default { type pulse }
> >}
> >]
>
> Just a quick question as I've not had a chance to try this out yet!
>
> Does your code consider pulse as unavailable if it's suspended?
Uh? Better not.
PA by default suspends sinks these days when they are not used. Hence
implementing what you requested doesn't really do any good.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
Sjoerd Simons wrote:
> Hi,
>
> The attached patch extends the alsa pulse plugin set with a alsa
> configuration hook. Allowing one to specify some configuration parameters
> that only come into effect when pulseaudio is running.
>
> For example a configution file like:
>
> @hooks [ {
>func on_pulse_is_running
> pcm.!default { type pulse }
> ctl.!default { type pulse }
>}
>]
Just a quick question as I've not had a chance to try this out yet!
Does your code consider pulse as unavailable if it's suspended?
e.g. by running:
$ pasuspender
Would the hook still try and push alsa sound via pulse?
It would rock if it didn't but I suspect it will :)
Col
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
On Mon, Apr 28, 2008 at 09:53:05AM +0100, Colin Guthrie wrote: > Sjoerd Simons wrote: > > The attached patch extends the alsa pulse plugin set with a alsa > > configuration hook. Allowing one to specify some configuration parameters > > that only come into effect when pulseaudio is running. > > I was waiting with baited breath after your chat on IRC as to what your > solution would actually be! > > I like it! > > I think the overhead at initialisation is probably OK, although I guess > it depends on how an application works - e.g. if it constant opens and > closes alsa connections then does this overhead mount up? If not then > this looks like a good solution. It unfortunately does add up. Otoh apps shouldn't open and close the audio device all the time :) And ideally should use pulseaudio directly. If i look at my personal desktop the only thing i actually still use that does uses pulse through alsa is VLC.. Which will have a pulse output option in the next release. If people are getting hit by the overhead they can disable the check and configure things manually. I think it's not too much of an overhead, but that's something only practise can show when people start using it in different situations. My feeling is that if your in a situation where the overhead gets noticible then your probably skilled enough to change the configuration :) > That said Lennart has said in the past that he didn't like the idea of > Alsa automatically falling back to h/w access if pulse isn't > responding. (this was in reference to tweaking the alsa plugin itself, > rather than this approach which is slightly different conceptually, > albeit with the same end goal). I think his comment at the time was "it > masks configuration problems". Resource-wise you could theoretically fallback in nicer ways. But that requires a lot more alsa knowledge then i have. The real issue is that there is no good way to decide between, ``this user doesn't use pulse'' and ``this user wants to use pulse but some problem occured'' What i'm currently unsure of is that the patch only declares pulse as running if it succeeds in getting a full connection. Maybe, to be sure we don't hide certain problems it should also declare pulse as running even if say authentication fails. Sjoerd -- Round Numbers are always false. -- Samuel Johnson ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
Sjoerd Simons wrote: > The attached patch extends the alsa pulse plugin set with a alsa > configuration hook. Allowing one to specify some configuration parameters > that only come into effect when pulseaudio is running. I was waiting with baited breath after your chat on IRC as to what your solution would actually be! I like it! I think the overhead at initialisation is probably OK, although I guess it depends on how an application works - e.g. if it constant opens and closes alsa connections then does this overhead mount up? If not then this looks like a good solution. That said Lennart has said in the past that he didn't like the idea of Alsa automatically falling back to h/w access if pulse isn't responding. (this was in reference to tweaking the alsa plugin itself, rather than this approach which is slightly different conceptually, albeit with the same end goal). I think his comment at the time was "it masks configuration problems". Do you have any thoughts on this Lennart? Col ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Pulseaudio alsa configure hook
Hi,
The attached patch extends the alsa pulse plugin set with a alsa
configuration hook. Allowing one to specify some configuration parameters
that only come into effect when pulseaudio is running.
For example a configution file like:
@hooks [ {
func on_pulse_is_running
pcm.!default { type pulse }
ctl.!default { type pulse }
}
]
will redirect the default alsa pcm and ctl to pulse iff pulse is running.
(Assuming you defined the hook function correctly ofcourse)
This is usefull for distributions that don't want to force their users to
switch completely to pulseaudio, but have things a bit more dynamic :)
The solutions isn't optimal though. It will mean that every program loading
accessing alsa will try to make an (extra) connection to pulse to decide what
to do. But i think it's the best we can do for now (or at least that i can do
with my minimal knowledge of alsa).
A nicer solution would be a way to always specify the pulse plugin as default
and have a sort of fallback for when that fails.
Comments on the patch appreciated :)
Sjoerd
PS: I'm not on alsa-devel, so please keep me in the CC
--
GREAT MOMENTS IN HISTORY (#7): April 2, 1751
Issac Newton becomes discouraged when he falls up a flight of stairs.
diff -r 1c30b7b2a8a3 pulse/Makefile.am
--- a/pulse/Makefile.am Tue Apr 22 18:34:03 2008 +0200
+++ b/pulse/Makefile.am Sun Apr 27 22:19:32 2008 +0200
@@ -1,8 +1,10 @@
asound_module_pcm_LTLIBRARIES = libasound_module_pcm_pulse.la
asound_module_ctl_LTLIBRARIES = libasound_module_ctl_pulse.la
+asound_module_conf_LTLIBRARIES = libasound_module_conf_pulse.la
asound_module_pcmdir = @ALSA_PLUGIN_DIR@
asound_module_ctldir = @ALSA_PLUGIN_DIR@
+asound_module_confdir = @ALSA_PLUGIN_DIR@
AM_CFLAGS = -Wall -g @ALSA_CFLAGS@ $(PTHREAD_CFLAGS) $(pulseaudio_CFLAGS) -D_GNU_SOURCE
AM_LDFLAGS = -module -avoid-version -export-dynamic -no-undefined
@@ -12,3 +14,6 @@
libasound_module_ctl_pulse_la_SOURCES = ctl_pulse.c pulse.c pulse.h
libasound_module_ctl_pulse_la_LIBADD = @ALSA_LIBS@ $(PTHREAD_LIBS) $(pulseaudio_LIBS)
+
+libasound_module_conf_pulse_la_SOURCES = conf_pulse.c
+libasound_module_conf_pulse_la_LIBADD = @ALSA_LIBS@ $(PTHREAD_LIBS) $(pulseaudio_LIBS)
diff -r 1c30b7b2a8a3 pulse/conf_pulse.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/pulse/conf_pulse.c Sun Apr 27 22:19:32 2008 +0200
@@ -0,0 +1,88 @@
+/*
+ * ALSA configuration function extensions for pulse
+ *
+ * Copyright (c) 2008 by Sjoerd Simons <[EMAIL PROTECTED]>
+ *
+ * This library is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as
+ * published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ * 02111-1307 USA
+ *
+ */
+
+#include
+
+#include
+#include
+
+
+int
+conf_pulse_hook_on_is_running (snd_config_t *root, snd_config_t *config,
+snd_config_t **dst, snd_config_t *private_data) {
+ snd_config_t *n = NULL;
+ pa_mainloop *loop = NULL;
+ pa_context *context = NULL;
+ int ret = 0, err, state;
+
+
+ /* Defined if we're called inside the pulsedaemon itself */
+ if (getenv("PULSE_INTERNAL") != NULL)
+goto out;
+
+ loop = pa_mainloop_new();
+ if (loop == NULL)
+goto out;
+
+ context = pa_context_new(pa_mainloop_get_api(loop), "Alsa hook");
+ if (context == NULL)
+goto out;
+
+ err = pa_context_connect (context, NULL, 0, NULL);
+ if (err < 0)
+goto out;
+
+ do {
+err = pa_mainloop_prepare (loop, -1);
+if (err < 0)
+ goto out;
+
+err = pa_mainloop_poll (loop);
+if (err < 0)
+ goto out;
+
+err = pa_mainloop_dispatch (loop);
+if (err < 0)
+ goto out;
+
+state = pa_context_get_state(context);
+ } while (state < PA_CONTEXT_READY);
+
+ if (state != PA_CONTEXT_READY)
+goto out;
+
+ ret = snd_config_expand(config, root, NULL, private_data, &n);
+
+out:
+ if (context != NULL)
+pa_context_unref(context);
+
+ if (loop != NULL)
+pa_mainloop_free(loop);
+
+ *dst = n;
+
+ return ret;
+}
+
+SND_DLSYM_BUILD_VERSION(conf_pulse_hook_on_is_running,
+ SND_CONFIG_DLSYM_VERSION_HOOK);
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
