[PATCH 0/3] Fallback mechanism for pulse plugin

[PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

Hi,

the following are experimental patches for implementing the fallback
option of PCM / control pulse plugin.  When the connection to PA
server fails, the plugin tries to open the fallback name.

For achieving this, I added the new standard definition "sysdefault",
which is equal with the normal "default" PCM / control definitions.
The difference is only the name, i.e. it won't be overridden by other
setups.  Then two new API functions for opening a fallback PCM /
control, and finally a patch for pulse-plugin will follow.  All
changes are relatively small and easy.

Let me know if you have any suggestions or a better idea.


thanks,

Takashi

[PATCH 1/3] Define "sysdefault" PCM and control

[Takashi Iwai]

When "default" PCM and control definitions are overwritten by others
like PulseAudio setup, the original system-default defition is lost.
This is a problem when PA is temporarily (or intentionally) disabled
and user wants to use the default dmix.

This patch adds a new standard definition for the system-default,
"sysdefault".  This can be used for fallbacks.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 src/conf/alsa.conf |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/conf/alsa.conf b/src/conf/alsa.conf
index 1889f01..f039e3d 100644
--- a/src/conf/alsa.conf
+++ b/src/conf/alsa.conf
@@ -118,7 +118,8 @@ defaults.timer.subdevice 0
 # redirect to load-on-demand extended pcm definitions
 pcm.cards cards.pcm
 
-pcm.default cards.pcm.default
+pcm.sysdefault cards.pcm.default
+pcm.default pcm.sysdefault
 pcm.front cards.pcm.front
 pcm.rear cards.pcm.rear
 pcm.center_lfe cards.pcm.center_lfe
@@ -321,7 +322,7 @@ pcm.null {
 #  Control interface
 #
 	
-ctl.default {
+ctl.sysdefault {
 	type hw
 	card {
 		@func getenv
@@ -335,6 +336,7 @@ ctl.default {
 		}
 	}
 }
+ctl.default ctl.sysdefault
 
 ctl.hw {
 	@args [ CARD ]
-- 
1.7.6

[PATCH 2/3] Add snd_{ctl|pcm}_open_fallback() functions

[Takashi Iwai]

This patch adds new API functions, snd_ctl_open_fallback() and
snd_pcm_open_fallback().  These are just like snd_*_open_lconf() but
used to open a fallback PCM/control.  The difference is that it replaces
the name string with the given original name, so that hctl and other
upper-layers will recognize it as an alias.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 include/control.h     |    1 +
 include/pcm.h         |    3 +++
 src/control/control.c |   22 ++++++++++++++++++++++
 src/pcm/pcm.c         |   24 ++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/include/control.h b/include/control.h
index e8f38bb..f265e34 100644
--- a/include/control.h
+++ b/include/control.h
@@ -224,6 +224,7 @@ char *snd_device_name_get_hint(const void *hint, const char *id);
 
 int snd_ctl_open(snd_ctl_t **ctl, const char *name, int mode);
 int snd_ctl_open_lconf(snd_ctl_t **ctl, const char *name, int mode, snd_config_t *lconf);
+int snd_ctl_open_fallback(snd_ctl_t **ctl, snd_config_t *root, const char *name, const char *orig_name, int mode);
 int snd_ctl_close(snd_ctl_t *ctl);
 int snd_ctl_nonblock(snd_ctl_t *ctl, int nonblock);
 int snd_async_add_ctl_handler(snd_async_handler_t **handler, snd_ctl_t *ctl, 
diff --git a/include/pcm.h b/include/pcm.h
index 7243ffb..be355a9 100644
--- a/include/pcm.h
+++ b/include/pcm.h
@@ -410,6 +410,9 @@ int snd_pcm_open(snd_pcm_t **pcm, const char *name,
 int snd_pcm_open_lconf(snd_pcm_t **pcm, const char *name, 
 		       snd_pcm_stream_t stream, int mode,
 		       snd_config_t *lconf);
+int snd_pcm_open_fallback(snd_pcm_t **pcm, snd_config_t *root,
+			  const char *name, const char *orig_name,
+			  snd_pcm_stream_t stream, int mode);
 
 int snd_pcm_close(snd_pcm_t *pcm);
 const char *snd_pcm_name(snd_pcm_t *pcm);
diff --git a/src/control/control.c b/src/control/control.c
index 19e9389..cd17c6f 100644
--- a/src/control/control.c
+++ b/src/control/control.c
@@ -919,6 +919,28 @@ int snd_ctl_open_lconf(snd_ctl_t **ctlp, const char *name,
 	return snd_ctl_open_noupdate(ctlp, lconf, name, mode);
 }
 
+/**
+ * \brief Opens a fallback CTL
+ * \param ctlp Returned CTL handle
+ * \param root Configuration root
+ * \param name ASCII identifier of the CTL handle used as fallback
+ * \param orig_name The original ASCII name
+ * \param mode Open mode (see #SND_CTL_NONBLOCK, #SND_CTL_ASYNC)
+ * \return 0 on success otherwise a negative error code
+ */
+int snd_ctl_open_fallback(snd_ctl_t **ctlp, snd_config_t *root,
+			  const char *name, const char *orig_name, int mode)
+{
+	int err;
+	assert(ctlp && name && root);
+	err = snd_ctl_open_noupdate(ctlp, root, name, mode);
+	if (err >= 0) {
+		free((*ctlp)->name);
+		(*ctlp)->name = orig_name ? strdup(orig_name) : NULL;
+	}
+	return err;
+}
+
 #ifndef DOC_HIDDEN
 #define TYPE(v) [SND_CTL_ELEM_TYPE_##v] = #v
 #define IFACE(v) [SND_CTL_ELEM_IFACE_##v] = #v
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
index 02dea0d..12f8cd0 100644
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2259,6 +2259,30 @@ int snd_pcm_open_lconf(snd_pcm_t **pcmp, const char *name,
 	return snd_pcm_open_noupdate(pcmp, lconf, name, stream, mode, 0);
 }
 
+/**
+ * \brief Opens a fallback PCM
+ * \param pcmp Returned PCM handle
+ * \param root Configuration root
+ * \param name ASCII identifier of the PCM handle
+ * \param orig_name The original ASCII name
+ * \param stream Wanted stream
+ * \param mode Open mode (see #SND_PCM_NONBLOCK, #SND_PCM_ASYNC)
+ * \return 0 on success otherwise a negative error code
+ */
+int snd_pcm_open_fallback(snd_pcm_t **pcmp, snd_config_t *root,
+			  const char *name, const char *orig_name,
+			  snd_pcm_stream_t stream, int mode)
+{
+	int err;
+	assert(pcmp && name && root);
+	err = snd_pcm_open_noupdate(pcmp, root, name, stream, mode, 0);
+	if (err >= 0) {
+		free((*pcmp)->name);
+		(*pcmp)->name = orig_name ? strdup(orig_name) : NULL;
+	}
+	return err;
+}
+
 #ifndef DOC_HIDDEN
 int snd_pcm_new(snd_pcm_t **pcmp, snd_pcm_type_t type, const char *name,
 		snd_pcm_stream_t stream, int mode)
-- 
1.7.6

[PATCH 3/3] pulse: Add fallback option

[Takashi Iwai]

[Patch to alsa-plugins]

Added "fallback" option to give the PCM / controller name as a fallback
when connecting to PA server fails.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 doc/README-pulse  |   19 +++++++++++++++++++
 pulse/ctl_pulse.c |   17 ++++++++++++++++-
 pulse/pcm_pulse.c |   17 ++++++++++++++++-
 pulse/pulse.c     |    7 ++++---
 pulse/pulse.h     |    2 +-
 5 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/doc/README-pulse b/doc/README-pulse
index d5431b4..5b119f9 100644
--- a/doc/README-pulse
+++ b/doc/README-pulse
@@ -39,3 +39,22 @@ you need to do this with PCM:s then specify two PCM:s with different "device".
 
 If you do not specify any source and/or sink, then the server's defaults will
 be used.
+
+When "fallback" option is set, the plugin will try to open the given PCM
+(or control) automatically when connecting to PA server fails.  Typically,
+it should point to "sysdefault", which was introduced recently in alsa-lib,
+so that the system-default setup is used even when you overwrite "default"
+PCM and control definitions.
+
+    pcm.pulse {
+        type pulse
+        fallback "sysdefault"
+    }
+
+    ctl.pulse {
+        type pulse
+        fallback "sysdefault"
+    }
+
+   pcm.!default "pulse"
+   ctl.!default "pulse"
diff --git a/pulse/ctl_pulse.c b/pulse/ctl_pulse.c
index 85863ed..8b5ff9e 100644
--- a/pulse/ctl_pulse.c
+++ b/pulse/ctl_pulse.c
@@ -647,6 +647,7 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 	const char *device = NULL;
 	const char *source = NULL;
 	const char *sink = NULL;
+	const char *fallback_name = NULL;
 	int err;
 	snd_ctl_pulse_t *ctl;
 	pa_operation *o;
@@ -687,10 +688,20 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 			}
 			continue;
 		}
+		if (strcmp(id, "fallback") == 0) {
+			if (snd_config_get_string(n, &fallback_name) < 0) {
+				SNDERR("Invalid value for %s", id);
+				return -EINVAL;
+			}
+			continue;
+		}
 		SNDERR("Unknown field %s", id);
 		return -EINVAL;
 	}
 
+	if (fallback_name && name && !strcmp(name, fallback_name))
+		fallback_name = NULL; /* no fallback for the same name */
+
 	ctl = calloc(1, sizeof(*ctl));
 	if (!ctl)
 		return -ENOMEM;
@@ -701,7 +712,7 @@ SND_CTL_PLUGIN_DEFINE_FUNC(pulse)
 		goto error;
 	}
 
-	err = pulse_connect(ctl->p, server);
+	err = pulse_connect(ctl->p, server, !fallback_name);
 	if (err < 0)
 		goto error;
 
@@ -794,6 +805,10 @@ error:
 	free(ctl->sink);
 	free(ctl);
 
+	if (fallback_name)
+		return snd_ctl_open_fallback(handlep, root,
+					     fallback_name, name, mode);
+
 	return err;
 }
 
diff --git a/pulse/pcm_pulse.c b/pulse/pcm_pulse.c
index 9105d4d..15b29e0 100644
--- a/pulse/pcm_pulse.c
+++ b/pulse/pcm_pulse.c
@@ -982,6 +982,7 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 	snd_config_iterator_t i, next;
 	const char *server = NULL;
 	const char *device = NULL;
+	const char *fallback_name = NULL;
 	int handle_underrun = 0;
 	int err;
 	snd_pcm_pulse_t *pcm;
@@ -1016,10 +1017,20 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 			handle_underrun = err;
 			continue;
 		}
+		if (strcmp(id, "fallback") == 0) {
+			if (snd_config_get_string(n, &fallback_name) < 0) {
+				SNDERR("Invalid value for %s", id);
+				return -EINVAL;
+			}
+			continue;
+		}
 		SNDERR("Unknown field %s", id);
 		return -EINVAL;
 	}
 
+	if (fallback_name && name && !strcmp(name, fallback_name))
+		fallback_name = NULL; /* no fallback for the same name */
+
 	pcm = calloc(1, sizeof(*pcm));
 	if (!pcm)
 		return -ENOMEM;
@@ -1041,7 +1052,7 @@ SND_PCM_PLUGIN_DEFINE_FUNC(pulse)
 
 	pcm->handle_underrun = handle_underrun;
 
-	err = pulse_connect(pcm->p, server);
+	err = pulse_connect(pcm->p, server, !fallback_name);
 	if (err < 0)
 		goto error;
 
@@ -1074,6 +1085,10 @@ error:
 	free(pcm->device);
 	free(pcm);
 
+	if (fallback_name)
+		return snd_pcm_open_fallback(pcmp, root, fallback_name, name,
+					     stream, mode);
+
 	return err;
 }
 
diff --git a/pulse/pulse.c b/pulse/pulse.c
index f26363a..6d9613d 100644
--- a/pulse/pulse.c
+++ b/pulse/pulse.c
@@ -188,7 +188,7 @@ void pulse_free(snd_pulse_t * p)
 	free(p);
 }
 
-int pulse_connect(snd_pulse_t * p, const char *server)
+int pulse_connect(snd_pulse_t * p, const char *server, int show_error)
 {
 	int err;
 	pa_context_state_t state;
@@ -225,8 +225,9 @@ int pulse_connect(snd_pulse_t * p, const char *server)
 	return 0;
 
       error:
-	SNDERR("PulseAudio: Unable to connect: %s\n",
-		pa_strerror(pa_context_errno(p->context)));
+	if (show_error)
+		SNDERR("PulseAudio: Unable to connect: %s\n",
+		       pa_strerror(pa_context_errno(p->context)));
 
 	pa_threaded_mainloop_unlock(p->mainloop);
 
diff --git a/pulse/pulse.h b/pulse/pulse.h
index e98124f..9f32a7f 100644
--- a/pulse/pulse.h
+++ b/pulse/pulse.h
@@ -42,7 +42,7 @@ int pulse_wait_operation(snd_pulse_t * p, pa_operation * o);
 snd_pulse_t *pulse_new(void);
 void pulse_free(snd_pulse_t * p);
 
-int pulse_connect(snd_pulse_t * p, const char *server);
+int pulse_connect(snd_pulse_t * p, const char *server, int show_error);
 
 void pulse_poll_activate(snd_pulse_t * p);
 void pulse_poll_deactivate(snd_pulse_t * p);
-- 
1.7.6

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

Hi,

Sorry for the late reply.

'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
> Hi,
> 
> the following are experimental patches for implementing the fallback
> option of PCM / control pulse plugin.  When the connection to PA
> server fails, the plugin tries to open the fallback name.
> 
> For achieving this, I added the new standard definition "sysdefault",
> which is equal with the normal "default" PCM / control definitions.
> The difference is only the name, i.e. it won't be overridden by other
> setups.  Then two new API functions for opening a fallback PCM /
> control, and finally a patch for pulse-plugin will follow.  All
> changes are relatively small and easy.
> 
> Let me know if you have any suggestions or a better idea.

Personally I don't really like this idea at all.

If the connection fails, then it could hog the device preventing other
clients from working correctly.

This could happen e.g. if you do:

PULSE_SERVER=192.168.1.99 aplay some.wav

Here it is quite expected that the connection will fail if the network
is down but the last thing I want it to do is to open the local sound
device.

The same would be true if you SSH'ed to a remote machine, taking the PA
connection config with you in the X11 root window PULSE_SERVER property.
If the user has not enabled their tcp protocol option or doesn't have
the relevant port open on their firewall, then you really don't want
them to open the sound device on the remote machine.

So while I can see some use cases for this, I think it would be much
better to ensure that if the user wants to use PA, that their asoundrc
setup is just configured correctly, not have any kind of automatic
fallback. I have made similar complaints against the approach Ubuntu
take here... it's quite different in that they have a dynamic "asoundrc"
type config before it even speaks to the module.

In their case there are many corner cases relating to non-local PAs, but
in that case the opposite problem is true, i.e. it will NOT use a remote
PA if a local one is not running...

So really, I'd very much like to not have this support in here as it'll
just make debugging many times harder for me. I'd also like to see the
Ubuntu system removed too.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Consider revert? (was Re: [PATCH 0/3] Fallback mechanism for pulse plugin)

[Colin Guthrie]

I've only just noticed that this patch series has already been committed
to the tree.

As stated below, I really don't think it's a good idea to activate this.
And if it's not activated, are there any other non-PA related cases
where this makes sense? If not, perhaps this API should be reverted
before an official release if you agree with my comments below.

Col


'Twas brillig, and Colin Guthrie at 03/09/11 16:27 did gyre and gimble:
> Hi,
> 
> Sorry for the late reply.
> 
> 'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
>> Hi,
>>
>> the following are experimental patches for implementing the fallback
>> option of PCM / control pulse plugin.  When the connection to PA
>> server fails, the plugin tries to open the fallback name.
>>
>> For achieving this, I added the new standard definition "sysdefault",
>> which is equal with the normal "default" PCM / control definitions.
>> The difference is only the name, i.e. it won't be overridden by other
>> setups.  Then two new API functions for opening a fallback PCM /
>> control, and finally a patch for pulse-plugin will follow.  All
>> changes are relatively small and easy.
>>
>> Let me know if you have any suggestions or a better idea.
> 
> Personally I don't really like this idea at all.
> 
> If the connection fails, then it could hog the device preventing other
> clients from working correctly.
> 
> This could happen e.g. if you do:
> 
> PULSE_SERVER=192.168.1.99 aplay some.wav
> 
> Here it is quite expected that the connection will fail if the network
> is down but the last thing I want it to do is to open the local sound
> device.
> 
> The same would be true if you SSH'ed to a remote machine, taking the PA
> connection config with you in the X11 root window PULSE_SERVER property.
> If the user has not enabled their tcp protocol option or doesn't have
> the relevant port open on their firewall, then you really don't want
> them to open the sound device on the remote machine.
> 
> So while I can see some use cases for this, I think it would be much
> better to ensure that if the user wants to use PA, that their asoundrc
> setup is just configured correctly, not have any kind of automatic
> fallback. I have made similar complaints against the approach Ubuntu
> take here... it's quite different in that they have a dynamic "asoundrc"
> type config before it even speaks to the module.
> 
> In their case there are many corner cases relating to non-local PAs, but
> in that case the opposite problem is true, i.e. it will NOT use a remote
> PA if a local one is not running...
> 
> So really, I'd very much like to not have this support in here as it'll
> just make debugging many times harder for me. I'd also like to see the
> Ubuntu system removed too.
> 
> Col
> 


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 3/3] pulse: Add fallback option

[Raymond Yau]

2011/7/26 Takashi Iwai <tiwai@suse.de>:
> [Patch to alsa-plugins]
>
> Added "fallback" option to give the PCM / controller name as a fallback
> when connecting to PA server fails.
>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
>  doc/README-pulse  |   19 +++++++++++++++++++
>  pulse/ctl_pulse.c |   17 ++++++++++++++++-
>  pulse/pcm_pulse.c |   17 ++++++++++++++++-
>  pulse/pulse.c     |    7 ++++---
>  pulse/pulse.h     |    2 +-
>  5 files changed, 56 insertions(+), 6 deletions(-)
>
> diff --git a/doc/README-pulse b/doc/README-pulse
> index d5431b4..5b119f9 100644
> --- a/doc/README-pulse
> +++ b/doc/README-pulse
> @@ -39,3 +39,22 @@ you need to do this with PCM:s then specify two PCM:s with different "device".
>
>  If you do not specify any source and/or sink, then the server's defaults will
>  be used.
> +
> +When "fallback" option is set, the plugin will try to open the given PCM
> +(or control) automatically when connecting to PA server fails.  Typically,
> +it should point to "sysdefault", which was introduced recently in alsa-lib,
> +so that the system-default setup is used even when you overwrite "default"
> +PCM and control definitions.
> +
> +    pcm.pulse {
> +        type pulse
> +        fallback "sysdefault"
> +    }
> +
> +    ctl.pulse {
> +        type pulse
> +        fallback "sysdefault"
> +    }
> +
> +   pcm.!default "pulse"
> +   ctl.!default "pulse"

it seem that override "pulse" is not a good idea

a better way is just add "fallback" to default

pcm.!default {
    type pulse
    fallback "sysdefault"
    hint {
        description "Default"
    }
}

ctl.!default {
    type pulse
    fallback "sysdefault"
    hint {
        description "Default"
    }
}

Re: [PATCH 1/3] Define "sysdefault" PCM and control

[Raymond Yau]

2011/7/26 Takashi Iwai <tiwai@suse.de>:
> When "default" PCM and control definitions are overwritten by others
> like PulseAudio setup, the original system-default defition is lost.
> This is a problem when PA is temporarily (or intentionally) disabled
> and user wants to use the default dmix.

how can the system upgrade Pulseaudio package without stopping PA server ?

is there any official way for user to temporiarily or intentionally
disabled pulseaudio without uninstal pulseaudio or alsa-pulse plugin ?

override alsa-pulse plugin seem only affect those alsa application
only, it seem that those application which use pulse api can still
autospawn PA server

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

At Sat, 03 Sep 2011 17:27:29 +0200,
Colin Guthrie wrote:
> 
> Hi,
> 
> Sorry for the late reply.

And sorry for the late reply to this (as I've been on vacation until
today :)

> 'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
> > Hi,
> > 
> > the following are experimental patches for implementing the fallback
> > option of PCM / control pulse plugin.  When the connection to PA
> > server fails, the plugin tries to open the fallback name.
> > 
> > For achieving this, I added the new standard definition "sysdefault",
> > which is equal with the normal "default" PCM / control definitions.
> > The difference is only the name, i.e. it won't be overridden by other
> > setups.  Then two new API functions for opening a fallback PCM /
> > control, and finally a patch for pulse-plugin will follow.  All
> > changes are relatively small and easy.
> > 
> > Let me know if you have any suggestions or a better idea.
> 
> Personally I don't really like this idea at all.
> 
> If the connection fails, then it could hog the device preventing other
> clients from working correctly.
> 
> This could happen e.g. if you do:
> 
> PULSE_SERVER=192.168.1.99 aplay some.wav
> 
> Here it is quite expected that the connection will fail if the network
> is down but the last thing I want it to do is to open the local sound
> device.

In such a case, we can check $PULSE_SERVER in the plugin and disables
fallback for remote access.

> The same would be true if you SSH'ed to a remote machine, taking the PA
> connection config with you in the X11 root window PULSE_SERVER property.
> If the user has not enabled their tcp protocol option or doesn't have
> the relevant port open on their firewall, then you really don't want
> them to open the sound device on the remote machine.
> 
> So while I can see some use cases for this, I think it would be much
> better to ensure that if the user wants to use PA, that their asoundrc
> setup is just configured correctly, not have any kind of automatic
> fallback.

Sorry, this doesn't work.  The problem is that you may have multiple
desktop systems on a single machine, one with PA (e.g. GNOME) and one
without PA (e.g. for minimalist).  Usually a system with PA installed
has a global asoundrc hook.  Then this blocks the non-PA users.
It's why I had to come up with this solution after years struggle to
promote PA.

> I have made similar complaints against the approach Ubuntu
> take here... it's quite different in that they have a dynamic "asoundrc"
> type config before it even speaks to the module.
> 
> In their case there are many corner cases relating to non-local PAs, but
> in that case the opposite problem is true, i.e. it will NOT use a remote
> PA if a local one is not running...

If the remote-access is the only problem, it can be checked in the
plugin, no?

> So really, I'd very much like to not have this support in here as it'll
> just make debugging many times harder for me. I'd also like to see the
> Ubuntu system removed too.

I don't advertise this to be used as default at all.  It's just an
option for poor admins :)  Seriously, how many people would be using
the remote PA feature, in comparison with the number of people
complaining the conflict of PA setup?  A little bit more friendly
setup for non-PA user is needed in reality.


thanks,

Takashi

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

Hi,

'Twas brillig, and Takashi Iwai at 12/09/11 09:05 did gyre and gimble:
> At Sat, 03 Sep 2011 17:27:29 +0200,
> Colin Guthrie wrote:
>>
>> Hi,
>>
>> Sorry for the late reply.
> 
> And sorry for the late reply to this (as I've been on vacation until
> today :)

:)

>> 'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
>>> Hi,
>>>
>>> the following are experimental patches for implementing the fallback
>>> option of PCM / control pulse plugin.  When the connection to PA
>>> server fails, the plugin tries to open the fallback name.
>>>
>>> For achieving this, I added the new standard definition "sysdefault",
>>> which is equal with the normal "default" PCM / control definitions.
>>> The difference is only the name, i.e. it won't be overridden by other
>>> setups.  Then two new API functions for opening a fallback PCM /
>>> control, and finally a patch for pulse-plugin will follow.  All
>>> changes are relatively small and easy.
>>>
>>> Let me know if you have any suggestions or a better idea.
>>
>> Personally I don't really like this idea at all.
>>
>> If the connection fails, then it could hog the device preventing other
>> clients from working correctly.
>>
>> This could happen e.g. if you do:
>>
>> PULSE_SERVER=192.168.1.99 aplay some.wav
>>
>> Here it is quite expected that the connection will fail if the network
>> is down but the last thing I want it to do is to open the local sound
>> device.
> 
> In such a case, we can check $PULSE_SERVER in the plugin and disables
> fallback for remote access.

No, that won't be sufficient, see below.

>> The same would be true if you SSH'ed to a remote machine, taking the PA
>> connection config with you in the X11 root window PULSE_SERVER property.
>> If the user has not enabled their tcp protocol option or doesn't have
>> the relevant port open on their firewall, then you really don't want
>> them to open the sound device on the remote machine.
>>
>> So while I can see some use cases for this, I think it would be much
>> better to ensure that if the user wants to use PA, that their asoundrc
>> setup is just configured correctly, not have any kind of automatic
>> fallback.
> 
> Sorry, this doesn't work.  The problem is that you may have multiple
> desktop systems on a single machine, one with PA (e.g. GNOME) and one
> without PA (e.g. for minimalist).  Usually a system with PA installed
> has a global asoundrc hook.  Then this blocks the non-PA users.
> It's why I had to come up with this solution after years struggle to
> promote PA.

So you're talking about a multi-headed system here with multiple sound
cards - separated out for each individual user and allocated to seats by
e.g. systemd configuration?

In such a setup, would the user who is not using PA not have to define
their own default card anyway so as to use the one they have been
assigned (AFAIK, alsa will see all the cards and try to open the first
one it finds, not the first one which the current user has ACL access
on). PA obviously "Just works"(tm) in these kind of setups as it fully
enumerates the devices and ignores completely the ones it does not have
ACL access on.

So if the user wants to work in such a multi headed system, with
pure-alsa, then they'll have to do some manual setup to pick their
default device anyway. In which case this automated fallback is of
minimal usefulness practically speaking (assuming I'm correct about the
device enumeration stuff in pure alsa).

If you are talking about a system whereby several, separate users can
log on to the same seat, but at different times (fast user switching),
then I can see this being more desirable.

That said, I still don't like automated fallbacks. If a user has chosen
to use PA, I firmly believe that's what they should get. It should
fallback under any circumstances as momentary errors could result in
apps being run in an even more unfamiliar setup compounding any
strangeness in the operation of their computer which will lead to more
problems for us upstream.

I would support a static config fallback such that there is a
system-wide and user-specific option that can be turned on/off to say "I
want to use PA", but I really do not want this to be a
try/fail/alternative type system.


>> I have made similar complaints against the approach Ubuntu
>> take here... it's quite different in that they have a dynamic "asoundrc"
>> type config before it even speaks to the module.
>>
>> In their case there are many corner cases relating to non-local PAs, but
>> in that case the opposite problem is true, i.e. it will NOT use a remote
>> PA if a local one is not running...
> 
> If the remote-access is the only problem, it can be checked in the
> plugin, no?

No, as PA config is not simply PULSE_SERVER env var. It's also the
PULSE_SERVER x11 root window property (which allows seamless SSHing to
other machines), so the plugin would also have to check that and thus be
linked against X11, then you would also have to check the client.conf
file both user-specific and systemwise as it too can specify a
"default-server" option.

It isn't really practical to duplicate the logic in the plugin, so if
this system were to be used, we'd have to provide some kind of
config-test binary in PA itself to do the checks needed and you'd have
to shell out to it and check the return value or similar.

All in all I think it's just too complex to try and model in an
automated way and when it goes wrong, it's really confusing and will be
hard to debug.

As I said above, I'd much rather a system where by we can check for a
known config file (/etc/pulseaudio/daemon.conf
$HOME/.pulseaudio/daemon.conf)? which specifies whether the user wants
to use PulseAudio or not (defaults to true).

I'd even be happy enough to modify PA to not startup when enabled=false
is found in that config file when started explicityly so this would also
take care of not starting the PA daemon for these "opting out user" via
XDG Autostart files which would currently be the case. In case you don't
know, PA will automatically start in an X11 session, so even with this
config in place, there still needs to be a separate configuration step
made for the user to prevent this from happening when they log in. That
problem is not solved by this patch, and in fact, when PA daemon is
started by XDG, the PA daemon is running and thus this the user would
use PA anyway, so it's probably worth thinking about the whole problem
rather than just this part and coming up with a full solution.

All in all, I think a much more holistic solution can be done with a
static config approach - one that works for users both opting in and
opting out and can be much more deterministic, but still give user-level
granularity.

Do you agree?


>> So really, I'd very much like to not have this support in here as it'll
>> just make debugging many times harder for me. I'd also like to see the
>> Ubuntu system removed too.
> 
> I don't advertise this to be used as default at all.  It's just an
> option for poor admins :)  Seriously, how many people would be using
> the remote PA feature, in comparison with the number of people
> complaining the conflict of PA setup?  A little bit more friendly
> setup for non-PA user is needed in reality.

Oh, trust me Ubuntu would likely end up using it by default as their
current hacks are quite similar. It's already annoying enough there.

I think the same usefulness can be achieved with static configs but in a
much more deterministic way and one which doesn't have strange corner cases.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

At Mon, 12 Sep 2011 09:46:19 +0100,
Colin Guthrie wrote:
> 
> Hi,
> 
> 'Twas brillig, and Takashi Iwai at 12/09/11 09:05 did gyre and gimble:
> > At Sat, 03 Sep 2011 17:27:29 +0200,
> > Colin Guthrie wrote:
> >>
> >> Hi,
> >>
> >> Sorry for the late reply.
> > 
> > And sorry for the late reply to this (as I've been on vacation until
> > today :)
> 
> :)
> 
> >> 'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
> >>> Hi,
> >>>
> >>> the following are experimental patches for implementing the fallback
> >>> option of PCM / control pulse plugin.  When the connection to PA
> >>> server fails, the plugin tries to open the fallback name.
> >>>
> >>> For achieving this, I added the new standard definition "sysdefault",
> >>> which is equal with the normal "default" PCM / control definitions.
> >>> The difference is only the name, i.e. it won't be overridden by other
> >>> setups.  Then two new API functions for opening a fallback PCM /
> >>> control, and finally a patch for pulse-plugin will follow.  All
> >>> changes are relatively small and easy.
> >>>
> >>> Let me know if you have any suggestions or a better idea.
> >>
> >> Personally I don't really like this idea at all.
> >>
> >> If the connection fails, then it could hog the device preventing other
> >> clients from working correctly.
> >>
> >> This could happen e.g. if you do:
> >>
> >> PULSE_SERVER=192.168.1.99 aplay some.wav
> >>
> >> Here it is quite expected that the connection will fail if the network
> >> is down but the last thing I want it to do is to open the local sound
> >> device.
> > 
> > In such a case, we can check $PULSE_SERVER in the plugin and disables
> > fallback for remote access.
> 
> No, that won't be sufficient, see below.
> 
> >> The same would be true if you SSH'ed to a remote machine, taking the PA
> >> connection config with you in the X11 root window PULSE_SERVER property.
> >> If the user has not enabled their tcp protocol option or doesn't have
> >> the relevant port open on their firewall, then you really don't want
> >> them to open the sound device on the remote machine.
> >>
> >> So while I can see some use cases for this, I think it would be much
> >> better to ensure that if the user wants to use PA, that their asoundrc
> >> setup is just configured correctly, not have any kind of automatic
> >> fallback.
> > 
> > Sorry, this doesn't work.  The problem is that you may have multiple
> > desktop systems on a single machine, one with PA (e.g. GNOME) and one
> > without PA (e.g. for minimalist).  Usually a system with PA installed
> > has a global asoundrc hook.  Then this blocks the non-PA users.
> > It's why I had to come up with this solution after years struggle to
> > promote PA.
> 
> So you're talking about a multi-headed system here with multiple sound
> cards - separated out for each individual user and allocated to seats by
> e.g. systemd configuration?

No, I'm talking a system with different desktop systems installed for
multiple users like the one below.

> In such a setup, would the user who is not using PA not have to define
> their own default card anyway so as to use the one they have been
> assigned (AFAIK, alsa will see all the cards and try to open the first
> one it finds, not the first one which the current user has ACL access
> on). PA obviously "Just works"(tm) in these kind of setups as it fully
> enumerates the devices and ignores completely the ones it does not have
> ACL access on.
> 
> So if the user wants to work in such a multi headed system, with
> pure-alsa, then they'll have to do some manual setup to pick their
> default device anyway. In which case this automated fallback is of
> minimal usefulness practically speaking (assuming I'm correct about the
> device enumeration stuff in pure alsa).
> 
> If you are talking about a system whereby several, separate users can
> log on to the same seat, but at different times (fast user switching),
> then I can see this being more desirable.

Yes, this is what I talked about.

> That said, I still don't like automated fallbacks. If a user has chosen
> to use PA, I firmly believe that's what they should get. It should
> fallback under any circumstances as momentary errors could result in
> apps being run in an even more unfamiliar setup compounding any
> strangeness in the operation of their computer which will lead to more
> problems for us upstream.

The problem is that it's difficult to teach users.  The admin wants a
single system-wide setup if possible.  Otherwise he'll get constantly
complains.

> I would support a static config fallback such that there is a
> system-wide and user-specific option that can be turned on/off to say "I
> want to use PA", but I really do not want this to be a
> try/fail/alternative type system.

Well, this needs yet another setup by user.  And users don't do that.
They just ignore anything they are told.

> >> I have made similar complaints against the approach Ubuntu
> >> take here... it's quite different in that they have a dynamic "asoundrc"
> >> type config before it even speaks to the module.
> >>
> >> In their case there are many corner cases relating to non-local PAs, but
> >> in that case the opposite problem is true, i.e. it will NOT use a remote
> >> PA if a local one is not running...
> > 
> > If the remote-access is the only problem, it can be checked in the
> > plugin, no?
> 
> No, as PA config is not simply PULSE_SERVER env var. It's also the
> PULSE_SERVER x11 root window property (which allows seamless SSHing to
> other machines), so the plugin would also have to check that and thus be
> linked against X11, then you would also have to check the client.conf
> file both user-specific and systemwise as it too can specify a
> "default-server" option.
> 
> It isn't really practical to duplicate the logic in the plugin, so if
> this system were to be used, we'd have to provide some kind of
> config-test binary in PA itself to do the checks needed and you'd have
> to shell out to it and check the return value or similar.
> 
> All in all I think it's just too complex to try and model in an
> automated way and when it goes wrong, it's really confusing and will be
> hard to debug.

Hrm, sounds so...

> As I said above, I'd much rather a system where by we can check for a
> known config file (/etc/pulseaudio/daemon.conf
> $HOME/.pulseaudio/daemon.conf)? which specifies whether the user wants
> to use PulseAudio or not (defaults to true).

It'll be anyway needed somehow.

> I'd even be happy enough to modify PA to not startup when enabled=false
> is found in that config file when started explicityly so this would also
> take care of not starting the PA daemon for these "opting out user" via
> XDG Autostart files which would currently be the case. In case you don't
> know, PA will automatically start in an X11 session, so even with this
> config in place, there still needs to be a separate configuration step
> made for the user to prevent this from happening when they log in. That
> problem is not solved by this patch, and in fact, when PA daemon is
> started by XDG, the PA daemon is running and thus this the user would
> use PA anyway, so it's probably worth thinking about the whole problem
> rather than just this part and coming up with a full solution.
> 
> All in all, I think a much more holistic solution can be done with a
> static config approach - one that works for users both opting in and
> opting out and can be much more deterministic, but still give user-level
> granularity.
> 
> Do you agree?

A sane static config solution would be nice in the first place, yes.
But, this is no solution for cases I've faced because it requires some
manual adjustment per user.
Again, as a golden rule: users don't read any manuals.  They login,
start something, and complain if fails.

Actually, other apps supporting PA seem doing the same thing already.
It falls back to other backends when PA connection failed.

> >> So really, I'd very much like to not have this support in here as it'll
> >> just make debugging many times harder for me. I'd also like to see the
> >> Ubuntu system removed too.
> > 
> > I don't advertise this to be used as default at all.  It's just an
> > option for poor admins :)  Seriously, how many people would be using
> > the remote PA feature, in comparison with the number of people
> > complaining the conflict of PA setup?  A little bit more friendly
> > setup for non-PA user is needed in reality.
> 
> Oh, trust me Ubuntu would likely end up using it by default as their
> current hacks are quite similar. It's already annoying enough there.
> I think the same usefulness can be achieved with static configs but in a
> much more deterministic way and one which doesn't have strange corner cases.

Well...  The ultimate goal is that to get a system working without
touching anything.  So, a config option doesn't fit with this big
picture.

Can we figure out the error reason from PA-lib?  For example, if
PA-lib returns an error code indicating that PA is disabled, we can
use a fallback mechanism.  OTOH, if PA's error is because of other
reasons (e.g. network down), the fallback shouldn't be used.


thanks,

Takashi

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

'Twas brillig, and Takashi Iwai at 12/09/11 10:23 did gyre and gimble:
>> If you are talking about a system whereby several, separate users can
>> log on to the same seat, but at different times (fast user switching),
>> then I can see this being more desirable.
> 
> Yes, this is what I talked about.
> 
>> That said, I still don't like automated fallbacks. If a user has chosen
>> to use PA, I firmly believe that's what they should get. It should
>> fallback under any circumstances as momentary errors could result in
>> apps being run in an even more unfamiliar setup compounding any
>> strangeness in the operation of their computer which will lead to more
>> problems for us upstream.
> 
> The problem is that it's difficult to teach users.  The admin wants a
> single system-wide setup if possible.  Otherwise he'll get constantly
> complains.

Very true.

>> I would support a static config fallback such that there is a
>> system-wide and user-specific option that can be turned on/off to say "I
>> want to use PA", but I really do not want this to be a
>> try/fail/alternative type system.
> 
> Well, this needs yet another setup by user.  And users don't do that.
> They just ignore anything they are told.

Sad, but also very true.


>> As I said above, I'd much rather a system where by we can check for a
>> known config file (/etc/pulseaudio/daemon.conf
>> $HOME/.pulseaudio/daemon.conf)? which specifies whether the user wants
>> to use PulseAudio or not (defaults to true).
> 
> It'll be anyway needed somehow.

Yup I think so. I'll put this on my list (I did try and suggest
something like this a while back, but got little in the way of responses
- I wanted to standardise things rather than have distro hacks
everywhere - can't seem to find the email now, so I'll just resend it
when I have some time to think straight)


>> I'd even be happy enough to modify PA to not startup when enabled=false
>> is found in that config file when started explicityly so this would also
>> take care of not starting the PA daemon for these "opting out user" via
>> XDG Autostart files which would currently be the case. In case you don't
>> know, PA will automatically start in an X11 session, so even with this
>> config in place, there still needs to be a separate configuration step
>> made for the user to prevent this from happening when they log in. That
>> problem is not solved by this patch, and in fact, when PA daemon is
>> started by XDG, the PA daemon is running and thus this the user would
>> use PA anyway, so it's probably worth thinking about the whole problem
>> rather than just this part and coming up with a full solution.
>>
>> All in all, I think a much more holistic solution can be done with a
>> static config approach - one that works for users both opting in and
>> opting out and can be much more deterministic, but still give user-level
>> granularity.
>>
>> Do you agree?
> 
> A sane static config solution would be nice in the first place, yes.
> But, this is no solution for cases I've faced because it requires some
> manual adjustment per user.
> Again, as a golden rule: users don't read any manuals.  They login,
> start something, and complain if fails.

Regardless, there would need to be some (distro specific?) GUI to
configure whether or not the user wants to use PA. A global (i.e.
system-wide) GUI to do this has existed in Mandriva for years, but I
don't fully know what other distros do. I presume SuSE has something in
YaST?

So the problem I have is thus:

 1. If the user wants to use PA and it's configure in the system that
way, then ALSA (or any other PA client) will autospawn PA if it's not
running. If that doesn't work, I would prefer that no ALSA-only fallback
happens as it masks where the real problem lies.

 2. If a given user does not want to use PA, but the system is
configured to run PA, then that user will typically have a PA daemon
started anyway via XDG autostart, unless they have specifically chosen
via their DE to override this startup option. In this scenario, PA is
running already and the automatic fallback stuff in the alsa-plugin
won't work as intended.

 3. If the system is not configured for PA but a given user does want to
use it, then the system will not run PA at login (due to hacks on the
XDG startup scripts and by setting autospawn=no in the
/etc/pulse/client.conf file), and thus the user will have to find a way
to start pulseaudio themselves (e.g. by copying the client.conf to their
own directory and setting autospawn=yes).


So these are the three scenarios we want to cover right?

If so, automatic systems are not really useful. In order for things to
work right, we really need to prevent both autospawn and manual XDG
spawn easily, both on a global and on a per-user basis.

> Actually, other apps supporting PA seem doing the same thing already.
> It falls back to other backends when PA connection failed.

This is true. You make a valid argument. I seem to be judging a alsa
client app in a different way to these other apps with specific PA
support + a fallback scheme for some reason. Not sure why I'm doing
that, but I suspect it relates to the "alsa fallback" in 99% of those
apps will be pure alsa, not automatic-fallback-alsa.

If you consider a setup whereby we have the following setup:

 1. autospawn=yes in global client.conf + no local client.conf
 2. enable=no in global daemon.conf + no local daemon.conf


The "enable" option is mythical - I've made it up, but it could be added.


If a client app that supports PA and has fallback to alsa, this is how
things would work:

 1. App tries Pulse.
 2. PA is not running, so libpulse tries autospawn.
 3. Autospawn fails (daemon exits due to enable=no config option)
 4. App determins Pulse is not available.
 5. App fallsback to ALSA
 6. ALSA tries Pulse.
 7. PA is not running, so libpulse tries autospawn.
 8. Autospawn fails (daemon exits due to enable=no config option)
 9. ALSA determins Pulse is not available.
 10. ALSA falls back to sysdefault.
 11. Whatever happens next....


So as you can see with the automatic system, we have the unnecessary
overhead of starting up twice.


Now with a static config, this wouldn't happen. Only one attempt would
be made (in the app) and by the time it reaches alsa, it already knows
we do not want to use PA and thus it doesn't even try to connect to PA.


So going back to my first three scenarios, the only actual case where an
automatic fallback helps is when the user has disabled PA. The rest of
the cases, the user may get some semblence of a working setup but so
many other things would break (e.g. keys for adjusting volume, OSDs
showing volume, panel mixer applets etc) that it is arguably worse to
give them a half working setup.

So the case where it really helps is when the user genuinely opts out of
PA. And if they genuinely do opt out, there are several things to do to
make it so anyway (like setting the autospawn to no in client.conf and
disabling the XDG autostart files), that making alsa config "just work"
is really of minimal usefulness.

So I still maintain that a static config is better for everyone. Make a
standard way to disable PA on a per-user basis, and make the alsa client
config tie into that easily.

Users who want PA will have breakage when things are broken at the PA
end, but that's likely more useful overall - it means the user will
report a bug and we can fix their setup.

User just just opt out, will be able to do so in a robust and officially
blessed way that kills of: 1. autospawn, 2. XDG startup, 3. Alsa
configuration all in one go.

Added to this, the corner cases where automatic fallback would fail are
avoided (and actually it's relatively common for users to use e.g. aplay
or another alsa client with a remote server for testing their PA network
setups and if the audio started coming out locally due to e.g. a
firewall issue, it would be really odd and would then break PA apps due
to the device hogging, so we really do want to cover this)


>>>> So really, I'd very much like to not have this support in here as it'll
>>>> just make debugging many times harder for me. I'd also like to see the
>>>> Ubuntu system removed too.
>>>
>>> I don't advertise this to be used as default at all.  It's just an
>>> option for poor admins :)  Seriously, how many people would be using
>>> the remote PA feature, in comparison with the number of people
>>> complaining the conflict of PA setup?  A little bit more friendly
>>> setup for non-PA user is needed in reality.
>>
>> Oh, trust me Ubuntu would likely end up using it by default as their
>> current hacks are quite similar. It's already annoying enough there.
>> I think the same usefulness can be achieved with static configs but in a
>> much more deterministic way and one which doesn't have strange corner cases.
> 
> Well...  The ultimate goal is that to get a system working without
> touching anything.  So, a config option doesn't fit with this big
> picture.

I really don't think this would work anyway. As I outlined above, if the
user opts out they *have* to touch some things (disabling PA autospawn
and preventing XDG autostart), so I think it's likely worth abandoning
the whole idea of "[not] touching anything".

> Can we figure out the error reason from PA-lib?  For example, if
> PA-lib returns an error code indicating that PA is disabled, we can
> use a fallback mechanism.  OTOH, if PA's error is because of other
> reasons (e.g. network down), the fallback shouldn't be used.

Perhaps, we'd likely need to add a new error code or similar for why the
connection failed.

But I think the only scenario you'd want to cover is if a local PA was
attempted to be spawned and it failed due to the server being disabled
(e.g. by the enable=no flag that I could add) or if autospawning itself
was disabled and no running server was found.

I will look into doing this, but as mentioned above, I think the user
will still need to do *something* to disable PA, even if the alsa side
of things "just works" when that is the case.

Col







-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

At Mon, 12 Sep 2011 19:39:59 +0100,
Colin Guthrie wrote:
> 
> 'Twas brillig, and Takashi Iwai at 12/09/11 10:23 did gyre and gimble:
> >> If you are talking about a system whereby several, separate users can
> >> log on to the same seat, but at different times (fast user switching),
> >> then I can see this being more desirable.
> > 
> > Yes, this is what I talked about.
> > 
> >> That said, I still don't like automated fallbacks. If a user has chosen
> >> to use PA, I firmly believe that's what they should get. It should
> >> fallback under any circumstances as momentary errors could result in
> >> apps being run in an even more unfamiliar setup compounding any
> >> strangeness in the operation of their computer which will lead to more
> >> problems for us upstream.
> > 
> > The problem is that it's difficult to teach users.  The admin wants a
> > single system-wide setup if possible.  Otherwise he'll get constantly
> > complains.
> 
> Very true.
> 
> >> I would support a static config fallback such that there is a
> >> system-wide and user-specific option that can be turned on/off to say "I
> >> want to use PA", but I really do not want this to be a
> >> try/fail/alternative type system.
> > 
> > Well, this needs yet another setup by user.  And users don't do that.
> > They just ignore anything they are told.
> 
> Sad, but also very true.
> 
> 
> >> As I said above, I'd much rather a system where by we can check for a
> >> known config file (/etc/pulseaudio/daemon.conf
> >> $HOME/.pulseaudio/daemon.conf)? which specifies whether the user wants
> >> to use PulseAudio or not (defaults to true).
> > 
> > It'll be anyway needed somehow.
> 
> Yup I think so. I'll put this on my list (I did try and suggest
> something like this a while back, but got little in the way of responses
> - I wanted to standardise things rather than have distro hacks
> everywhere - can't seem to find the email now, so I'll just resend it
> when I have some time to think straight)

Yeah, we want to have some really easy way to check whether PA is
enabled or not.  For example, in the case of X11, you can check
$DISPLAY (or options are given explicitly) as a primary check.


> >> I'd even be happy enough to modify PA to not startup when enabled=false
> >> is found in that config file when started explicityly so this would also
> >> take care of not starting the PA daemon for these "opting out user" via
> >> XDG Autostart files which would currently be the case. In case you don't
> >> know, PA will automatically start in an X11 session, so even with this
> >> config in place, there still needs to be a separate configuration step
> >> made for the user to prevent this from happening when they log in. That
> >> problem is not solved by this patch, and in fact, when PA daemon is
> >> started by XDG, the PA daemon is running and thus this the user would
> >> use PA anyway, so it's probably worth thinking about the whole problem
> >> rather than just this part and coming up with a full solution.
> >>
> >> All in all, I think a much more holistic solution can be done with a
> >> static config approach - one that works for users both opting in and
> >> opting out and can be much more deterministic, but still give user-level
> >> granularity.
> >>
> >> Do you agree?
> > 
> > A sane static config solution would be nice in the first place, yes.
> > But, this is no solution for cases I've faced because it requires some
> > manual adjustment per user.
> > Again, as a golden rule: users don't read any manuals.  They login,
> > start something, and complain if fails.
> 
> Regardless, there would need to be some (distro specific?) GUI to
> configure whether or not the user wants to use PA. A global (i.e.
> system-wide) GUI to do this has existed in Mandriva for years, but I
> don't fully know what other distros do. I presume SuSE has something in
> YaST?

SUSE provides a script to turn on/off PA globally.  I don't remember
whether this can be called from YaST, as I haven't checked it for long
time, though...

But one problem is that this setup is a global one.  There is no
trivial way for setting up for each user.

> So the problem I have is thus:
> 
>  1. If the user wants to use PA and it's configure in the system that
> way, then ALSA (or any other PA client) will autospawn PA if it's not
> running. If that doesn't work, I would prefer that no ALSA-only fallback
> happens as it masks where the real problem lies.

Right.  In this case, PA should have been started beforehand.  But,
the start-up is always racy, so it might happen that ALSA-pulse app is
kicked off before PA daemon gets started.  This is one possible
problem.

Another possible problem is when PA daemon crashes by some reason and
ALSA-pulse app is started just after it.

>  2. If a given user does not want to use PA, but the system is
> configured to run PA, then that user will typically have a PA daemon
> started anyway via XDG autostart, unless they have specifically chosen
> via their DE to override this startup option. In this scenario, PA is
> running already and the automatic fallback stuff in the alsa-plugin
> won't work as intended.

XDG isn't used in every environment.  Many window managers won't use
it.  So, there are two cases: 2a) PA starts up via XDG but user
doesn't want to use.  2b) PA doesn't start up and user doesn't want to
use PA.

>  3. If the system is not configured for PA but a given user does want to
> use it, then the system will not run PA at login (due to hacks on the
> XDG startup scripts and by setting autospawn=no in the
> /etc/pulse/client.conf file), and thus the user will have to find a way
> to start pulseaudio themselves (e.g. by copying the client.conf to their
> own directory and setting autospawn=yes).

Right.

> So these are the three scenarios we want to cover right?
> 
> If so, automatic systems are not really useful. In order for things to
> work right, we really need to prevent both autospawn and manual XDG
> spawn easily, both on a global and on a per-user basis.
> 
> > Actually, other apps supporting PA seem doing the same thing already.
> > It falls back to other backends when PA connection failed.
> 
> This is true. You make a valid argument. I seem to be judging a alsa
> client app in a different way to these other apps with specific PA
> support + a fallback scheme for some reason. Not sure why I'm doing
> that, but I suspect it relates to the "alsa fallback" in 99% of those
> apps will be pure alsa, not automatic-fallback-alsa.
> 
> If you consider a setup whereby we have the following setup:
> 
>  1. autospawn=yes in global client.conf + no local client.conf
>  2. enable=no in global daemon.conf + no local daemon.conf
> 
> 
> The "enable" option is mythical - I've made it up, but it could be added.
> 
> 
> If a client app that supports PA and has fallback to alsa, this is how
> things would work:
> 
>  1. App tries Pulse.
>  2. PA is not running, so libpulse tries autospawn.
>  3. Autospawn fails (daemon exits due to enable=no config option)
>  4. App determins Pulse is not available.
>  5. App fallsback to ALSA
>  6. ALSA tries Pulse.
>  7. PA is not running, so libpulse tries autospawn.
>  8. Autospawn fails (daemon exits due to enable=no config option)
>  9. ALSA determins Pulse is not available.
>  10. ALSA falls back to sysdefault.
>  11. Whatever happens next....
> 
> 
> So as you can see with the automatic system, we have the unnecessary
> overhead of starting up twice.

When the fallback is set, it passes PA_CONTEXT_NOAUTOSPAWN, so steps
2-8 will be skipped, thus no big problem here.

The problem by fallback is that the autospawn isn't triggered -- that
is, when ALSA-pulse app is started before PA daemon, it fails.
It means that the fallback option assumes that PA daemon is started
already in a certain way like XDG.  And the scenario 3 above is a
problem, indeed.  (The scenario 1 might have races in exceptional
cases, too.)


> Now with a static config, this wouldn't happen. Only one attempt would
> be made (in the app) and by the time it reaches alsa, it already knows
> we do not want to use PA and thus it doesn't even try to connect to PA.

Sure, a static config check can be put in the fallback easily once
when defined.

> So going back to my first three scenarios, the only actual case where an
> automatic fallback helps is when the user has disabled PA.

Well, it's rather the case 2b above -- for users with a simple / dumb
window manager without touching global setups.  They don't set any
flags but silently assume that PA isn't used because it's not started
manually.

> The rest of
> the cases, the user may get some semblence of a working setup but so
> many other things would break (e.g. keys for adjusting volume, OSDs
> showing volume, panel mixer applets etc) that it is arguably worse to
> give them a half working setup.

Yeah, but you can forget about these stuff.  If something doesn't work
without PA, it's the system's fault.  The fallback assumes that it
would work without PA.

> So the case where it really helps is when the user genuinely opts out of
> PA. And if they genuinely do opt out, there are several things to do to
> make it so anyway (like setting the autospawn to no in client.conf and
> disabling the XDG autostart files), that making alsa config "just work"
> is really of minimal usefulness.
> 
> So I still maintain that a static config is better for everyone. Make a
> standard way to disable PA on a per-user basis, and make the alsa client
> config tie into that easily.
> 
> Users who want PA will have breakage when things are broken at the PA
> end, but that's likely more useful overall - it means the user will
> report a bug and we can fix their setup.
> 
> User just just opt out, will be able to do so in a robust and officially
> blessed way that kills of: 1. autospawn, 2. XDG startup, 3. Alsa
> configuration all in one go.
> 
> Added to this, the corner cases where automatic fallback would fail are
> avoided (and actually it's relatively common for users to use e.g. aplay
> or another alsa client with a remote server for testing their PA network
> setups and if the audio started coming out locally due to e.g. a
> firewall issue, it would be really odd and would then break PA apps due
> to the device hogging, so we really do want to cover this)

Yes, I'm for an easy static config per user-basis, too.
However, another question is whether user must setup it to enable /
disable PA.  In other words, how to detect reliably whether the
running DE is supposed to use PA or not.

The current implementation checks PA connection as the indication of
PA-usage.  If there is a better way to know, it can be used instead in
the plugin.

> >>>> So really, I'd very much like to not have this support in here as it'll
> >>>> just make debugging many times harder for me. I'd also like to see the
> >>>> Ubuntu system removed too.
> >>>
> >>> I don't advertise this to be used as default at all.  It's just an
> >>> option for poor admins :)  Seriously, how many people would be using
> >>> the remote PA feature, in comparison with the number of people
> >>> complaining the conflict of PA setup?  A little bit more friendly
> >>> setup for non-PA user is needed in reality.
> >>
> >> Oh, trust me Ubuntu would likely end up using it by default as their
> >> current hacks are quite similar. It's already annoying enough there.
> >> I think the same usefulness can be achieved with static configs but in a
> >> much more deterministic way and one which doesn't have strange corner cases.
> > 
> > Well...  The ultimate goal is that to get a system working without
> > touching anything.  So, a config option doesn't fit with this big
> > picture.
> 
> I really don't think this would work anyway. As I outlined above, if the
> user opts out they *have* to touch some things (disabling PA autospawn
> and preventing XDG autostart), so I think it's likely worth abandoning
> the whole idea of "[not] touching anything".

Well, PA autospawn is a problem, but it happens only after starting an
PA-native app.  With the fallback, ALSA-native app won't autospawn.
XDG autostart isn't used by many DEs.  So, this use-case isn't so
unrealistic at all.

> > Can we figure out the error reason from PA-lib?  For example, if
> > PA-lib returns an error code indicating that PA is disabled, we can
> > use a fallback mechanism.  OTOH, if PA's error is because of other
> > reasons (e.g. network down), the fallback shouldn't be used.
> 
> Perhaps, we'd likely need to add a new error code or similar for why the
> connection failed.
> 
> But I think the only scenario you'd want to cover is if a local PA was
> attempted to be spawned and it failed due to the server being disabled
> (e.g. by the enable=no flag that I could add) or if autospawning itself
> was disabled and no running server was found.
> 
> I will look into doing this, but as mentioned above, I think the user
> will still need to do *something* to disable PA, even if the alsa side
> of things "just works" when that is the case.

As mentioned, I'm basically for the static-config solution.  It'll
cover more completely.  OTOH, there are corner-cases (like the
scenario 2b) to consider more...


thanks,

Takashi

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>> Yup I think so. I'll put this on my list (I did try and suggest
>> something like this a while back, but got little in the way of responses
>> - I wanted to standardise things rather than have distro hacks
>> everywhere - can't seem to find the email now, so I'll just resend it
>> when I have some time to think straight)
> 
> Yeah, we want to have some really easy way to check whether PA is
> enabled or not.  For example, in the case of X11, you can check
> $DISPLAY (or options are given explicitly) as a primary check.

Yeah, but sadly I don't think this is possible. The Ubuntu solution for
example works differently to yours. (Disclaimer, I've already said I
think this is ugly). It works by altering the config file dynamically
such that the default is either dmix or pulse depending on whether PA is
running. Of course "PA is running" is a broken check in the first place
(see the "ugly" word in my disclaimer!) as we could be dealing with thin
clients and remote PA daemons only, in which case there is no running
PA. The *only* client-side way to do sensible autodetection is to try
and connect and see if it works, but for a system that maniuplates
configs, making the connection before actually making a real connection
is just silly. Your approach is more sensible, but still has those
tricky corner cases due to not being able to export a simply variable
(such as $DISPLAY) or other mechanism for simple detection of a PA based
system.

>> Regardless, there would need to be some (distro specific?) GUI to
>> configure whether or not the user wants to use PA. A global (i.e.
>> system-wide) GUI to do this has existed in Mandriva for years, but I
>> don't fully know what other distros do. I presume SuSE has something in
>> YaST?
> 
> SUSE provides a script to turn on/off PA globally.  I don't remember
> whether this can be called from YaST, as I haven't checked it for long
> time, though...
> 
> But one problem is that this setup is a global one.  There is no
> trivial way for setting up for each user.

Yes, I did the same in Mandriva/Mageia, but it's global only. An option
to do this officially in PA configs would IMO solve this issue - the PA
configs can already be set to global (/etc/pulse/daemon.conf) or local
(~/.pulse/daemon.conf), so if that's all we use to define whether or not
we want PA, then we should be all set.

>> So the problem I have is thus:
>>
>>  1. If the user wants to use PA and it's configure in the system that
>> way, then ALSA (or any other PA client) will autospawn PA if it's not
>> running. If that doesn't work, I would prefer that no ALSA-only fallback
>> happens as it masks where the real problem lies.
> 
> Right.  In this case, PA should have been started beforehand.  But,
> the start-up is always racy, so it might happen that ALSA-pulse app is
> kicked off before PA daemon gets started.  This is one possible
> problem.

I've still not been able to nail down any races but I've had a handful
of bug reports that seem to suggest *something* racy is going on. I'll
be damned if I can spot it in the code tho'. :(

> Another possible problem is when PA daemon crashes by some reason and
> ALSA-pulse app is started just after it.

That shouldn't generally be a problem. We should autospawn in that case.
That said, I'm not sure if there is a sequence of precise timings that
would cause a problem here?

>>  2. If a given user does not want to use PA, but the system is
>> configured to run PA, then that user will typically have a PA daemon
>> started anyway via XDG autostart, unless they have specifically chosen
>> via their DE to override this startup option. In this scenario, PA is
>> running already and the automatic fallback stuff in the alsa-plugin
>> won't work as intended.
> 
> XDG isn't used in every environment.  Many window managers won't use
> it.  So, there are two cases: 2a) PA starts up via XDG but user
> doesn't want to use.  2b) PA doesn't start up and user doesn't want to
> use PA.

Well GNOME and KDE do and there are xdg compliance wrappers for others
too, so I wouldn't worry about the cases where it's not present (at
least for this example). We have to deal with the "fallout" when it is
present. i.e. the 2a).

>>  3. If the system is not configured for PA but a given user does want to
>> use it, then the system will not run PA at login (due to hacks on the
>> XDG startup scripts and by setting autospawn=no in the
>> /etc/pulse/client.conf file), and thus the user will have to find a way
>> to start pulseaudio themselves (e.g. by copying the client.conf to their
>> own directory and setting autospawn=yes).
> 
> Right.
> 
>> So these are the three scenarios we want to cover right?
>>
>> If so, automatic systems are not really useful. In order for things to
>> work right, we really need to prevent both autospawn and manual XDG
>> spawn easily, both on a global and on a per-user basis.
>>
>>> Actually, other apps supporting PA seem doing the same thing already.
>>> It falls back to other backends when PA connection failed.
>>
>> This is true. You make a valid argument. I seem to be judging a alsa
>> client app in a different way to these other apps with specific PA
>> support + a fallback scheme for some reason. Not sure why I'm doing
>> that, but I suspect it relates to the "alsa fallback" in 99% of those
>> apps will be pure alsa, not automatic-fallback-alsa.
>>
>> If you consider a setup whereby we have the following setup:
>>
>>  1. autospawn=yes in global client.conf + no local client.conf
>>  2. enable=no in global daemon.conf + no local daemon.conf
>>
>>
>> The "enable" option is mythical - I've made it up, but it could be added.
>>
>>
>> If a client app that supports PA and has fallback to alsa, this is how
>> things would work:
>>
>>  1. App tries Pulse.
>>  2. PA is not running, so libpulse tries autospawn.
>>  3. Autospawn fails (daemon exits due to enable=no config option)
>>  4. App determins Pulse is not available.
>>  5. App fallsback to ALSA
>>  6. ALSA tries Pulse.
>>  7. PA is not running, so libpulse tries autospawn.
>>  8. Autospawn fails (daemon exits due to enable=no config option)
>>  9. ALSA determins Pulse is not available.
>>  10. ALSA falls back to sysdefault.
>>  11. Whatever happens next....
>>
>>
>> So as you can see with the automatic system, we have the unnecessary
>> overhead of starting up twice.
> 
> When the fallback is set, it passes PA_CONTEXT_NOAUTOSPAWN, so steps
> 2-8 will be skipped, thus no big problem here.

I think you misunderstand. libalsa only tries pulse in step 6. libalsa
has not had a lookin in the app until step 6, so there is no way
anything in alsa or alsa-plugins could affect steps 1 through 6.
Remember this is an app that supports "PA natively + ALSA fallback" -
i.e. there are *two* layers of fallback in this case. That's what I'd
like to avoid.

HOwever, I can see steps 7-8 not being required.

> The problem by fallback is that the autospawn isn't triggered -- that
> is, when ALSA-pulse app is started before PA daemon, it fails.
> It means that the fallback option assumes that PA daemon is started
> already in a certain way like XDG.  And the scenario 3 above is a
> problem, indeed.  (The scenario 1 might have races in exceptional
> cases, too.)

Ugg, so it breaks autospawn too :( That *really* sucks. So all it takes
if for someone to have an aplay startup sound script and it breaks their
entire setup? :(

This system is just keeps creating corner cases!!! I really don't like
it :( For one thing this means you cannot have console alsa apps using
PA anymore. While I don't personally care about this, we did get quite a
few complaints about it before autospawn was default. We'll be the ones
taking the flack for this configuration.

>> Now with a static config, this wouldn't happen. Only one attempt would
>> be made (in the app) and by the time it reaches alsa, it already knows
>> we do not want to use PA and thus it doesn't even try to connect to PA.
> 
> Sure, a static config check can be put in the fallback easily once
> when defined.
> 
>> So going back to my first three scenarios, the only actual case where an
>> automatic fallback helps is when the user has disabled PA.
> 
> Well, it's rather the case 2b above -- for users with a simple / dumb
> window manager without touching global setups.  They don't set any
> flags but silently assume that PA isn't used because it's not started
> manually.

Just another one of the corner cases I'd very much like to avoid

>> The rest of
>> the cases, the user may get some semblence of a working setup but so
>> many other things would break (e.g. keys for adjusting volume, OSDs
>> showing volume, panel mixer applets etc) that it is arguably worse to
>> give them a half working setup.
> 
> Yeah, but you can forget about these stuff.  If something doesn't work
> without PA, it's the system's fault.  The fallback assumes that it
> would work without PA.

So you're saying that PA+non-PA should be treated as equal citizens in
the Desktop Environment. Becasue that's not the case. Both GNOME and KDE
are both targeting the recommended setup of PA. If you don't use PA,
then the user certainly gets a second class experience. This is 100%
intended and isn't going to change.

So you really have to consider these changes very carefully. I will
fully support and help develop a deterministic system here, but I just
cannot see any scenario where automatic checks will work reliably and
deterministically, especially now I learn that autospawn is disabled :(

>> So the case where it really helps is when the user genuinely opts out of
>> PA. And if they genuinely do opt out, there are several things to do to
>> make it so anyway (like setting the autospawn to no in client.conf and
>> disabling the XDG autostart files), that making alsa config "just work"
>> is really of minimal usefulness.
>>
>> So I still maintain that a static config is better for everyone. Make a
>> standard way to disable PA on a per-user basis, and make the alsa client
>> config tie into that easily.
>>
>> Users who want PA will have breakage when things are broken at the PA
>> end, but that's likely more useful overall - it means the user will
>> report a bug and we can fix their setup.
>>
>> User just just opt out, will be able to do so in a robust and officially
>> blessed way that kills of: 1. autospawn, 2. XDG startup, 3. Alsa
>> configuration all in one go.
>>
>> Added to this, the corner cases where automatic fallback would fail are
>> avoided (and actually it's relatively common for users to use e.g. aplay
>> or another alsa client with a remote server for testing their PA network
>> setups and if the audio started coming out locally due to e.g. a
>> firewall issue, it would be really odd and would then break PA apps due
>> to the device hogging, so we really do want to cover this)
> 
> Yes, I'm for an easy static config per user-basis, too.
> However, another question is whether user must setup it to enable /
> disable PA.  In other words, how to detect reliably whether the
> running DE is supposed to use PA or not.
> 
> The current implementation checks PA connection as the indication of
> PA-usage.  If there is a better way to know, it can be used instead in
> the plugin.

1. Check PA with full autospawn support.
2. I'll look at adding some kind of error state into the connection
stuff in libpulse that would give information about whether or not PA
should have been used or not, but something stopped us. The following
scenarios should be covered by this check:
 a. Attempted to connect to remote daemon, but failed (e.g. due to
firewall or simply a daemon not running on the remote end).
 b. No remote config, attempt to run PA (autospawn=yes, enable=yes) but
PA didn't start.

Under those two scenarios, you should fail. But if libpulse can somehow
tell you "no PA is not meant to be used here" (i.e. "no local daemon +
(autospawn=no || enable=no)") then you can undertake your fallback scheme.

I think this approach is more robust, and still gives you most of your
auto-configuration desires.

The user would very much still have to run $something do disable his PA
if the system uses it (i.e. echo "enable=no" > ~/.pulse/daemon.conf),
but that is something I think we'd have to live with.


>> I really don't think this would work anyway. As I outlined above, if the
>> user opts out they *have* to touch some things (disabling PA autospawn
>> and preventing XDG autostart), so I think it's likely worth abandoning
>> the whole idea of "[not] touching anything".
> 
> Well, PA autospawn is a problem, but it happens only after starting an
> PA-native app.  With the fallback, ALSA-native app won't autospawn.
> XDG autostart isn't used by many DEs.  So, this use-case isn't so
> unrealistic at all.

I think that's very wrong. "ALSA native" shouldn't be considered
differently to any other pulse client. To do so just breaks many of the
mechanisms we've specifically spent time and effort on to put in place
to make things "Just work". This is a massive backwards step to then
deliberately break these mechanisms :(

>>> Can we figure out the error reason from PA-lib?  For example, if
>>> PA-lib returns an error code indicating that PA is disabled, we can
>>> use a fallback mechanism.  OTOH, if PA's error is because of other
>>> reasons (e.g. network down), the fallback shouldn't be used.
>>
>> Perhaps, we'd likely need to add a new error code or similar for why the
>> connection failed.
>>
>> But I think the only scenario you'd want to cover is if a local PA was
>> attempted to be spawned and it failed due to the server being disabled
>> (e.g. by the enable=no flag that I could add) or if autospawning itself
>> was disabled and no running server was found.
>>
>> I will look into doing this, but as mentioned above, I think the user
>> will still need to do *something* to disable PA, even if the alsa side
>> of things "just works" when that is the case.
> 
> As mentioned, I'm basically for the static-config solution.  It'll
> cover more completely.  OTOH, there are corner-cases (like the
> scenario 2b) to consider more...

2b is easy. PA autospawn should work and start PA. It's then the same
case as 2a. The fact it was started by XDG or autospawn should be 100%
irrelevant to audio apps. It's an implementation detail. Maybe we'll be
started by systemds session lingering in the future? Who knows. The
point is that if the system is configured for PA it should use PA.

I want to avoid all the strange rules. I don't want to have to explain
to someone on our IRC channel (and believe me, *I'd* be the one getting
the fallout from this option, not you!) "Oh pulseaudio automatically
spawns if it's not running except if the app is an alsa app in which
case it doesn't but only if you've configured your alsa setup that way
so it really depends" Users don't really want to know *anything* about
Pulse or ALSA. They shouldn't care, they just want a system that works.
and I don't want to have to jump through hoops to do it.

I will help get the necessary info from libpulse about how to proceed,
but only after 1.0 is out the door (which should be soon). All I ask is
that you try to appreciate my concerns here and how there are many
legitimate use cases and operational steps that would be jeopardised by
the current implementation and do not do a release with the code as it
currently stands.

Cheers


Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

At Tue, 13 Sep 2011 09:47:06 +0100,
Colin Guthrie wrote:
> 
> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
> >> Yup I think so. I'll put this on my list (I did try and suggest
> >> something like this a while back, but got little in the way of responses
> >> - I wanted to standardise things rather than have distro hacks
> >> everywhere - can't seem to find the email now, so I'll just resend it
> >> when I have some time to think straight)
> > 
> > Yeah, we want to have some really easy way to check whether PA is
> > enabled or not.  For example, in the case of X11, you can check
> > $DISPLAY (or options are given explicitly) as a primary check.
> 
> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
> example works differently to yours. (Disclaimer, I've already said I
> think this is ugly). It works by altering the config file dynamically
> such that the default is either dmix or pulse depending on whether PA is
> running. Of course "PA is running" is a broken check in the first place
> (see the "ugly" word in my disclaimer!) as we could be dealing with thin
> clients and remote PA daemons only, in which case there is no running
> PA. The *only* client-side way to do sensible autodetection is to try
> and connect and see if it works, but for a system that maniuplates
> configs, making the connection before actually making a real connection
> is just silly. Your approach is more sensible, but still has those
> tricky corner cases due to not being able to export a simply variable
> (such as $DISPLAY) or other mechanism for simple detection of a PA based
> system.

Such an ugly trick should be really avoided, yes...


> >> Regardless, there would need to be some (distro specific?) GUI to
> >> configure whether or not the user wants to use PA. A global (i.e.
> >> system-wide) GUI to do this has existed in Mandriva for years, but I
> >> don't fully know what other distros do. I presume SuSE has something in
> >> YaST?
> > 
> > SUSE provides a script to turn on/off PA globally.  I don't remember
> > whether this can be called from YaST, as I haven't checked it for long
> > time, though...
> > 
> > But one problem is that this setup is a global one.  There is no
> > trivial way for setting up for each user.
> 
> Yes, I did the same in Mandriva/Mageia, but it's global only. An option
> to do this officially in PA configs would IMO solve this issue - the PA
> configs can already be set to global (/etc/pulse/daemon.conf) or local
> (~/.pulse/daemon.conf), so if that's all we use to define whether or not
> we want PA, then we should be all set.

Or, can we introduce an environment variable to indicate globally
whether the system is supposed to use PA or not explicitly?  It's
easier than looking through config files.

Alternatively, if PA-lib provides a simple function to return the
enablement state, it'd be fine, too.


> >> So the problem I have is thus:
> >>
> >>  1. If the user wants to use PA and it's configure in the system that
> >> way, then ALSA (or any other PA client) will autospawn PA if it's not
> >> running. If that doesn't work, I would prefer that no ALSA-only fallback
> >> happens as it masks where the real problem lies.
> > 
> > Right.  In this case, PA should have been started beforehand.  But,
> > the start-up is always racy, so it might happen that ALSA-pulse app is
> > kicked off before PA daemon gets started.  This is one possible
> > problem.
> 
> I've still not been able to nail down any races but I've had a handful
> of bug reports that seem to suggest *something* racy is going on. I'll
> be damned if I can spot it in the code tho'. :(

I remember vaguely XDG startup conflicts.  There are two startups, one
for GNOME and one for KDE, and both are started on KDE.  In addition,
the GNOME login sound might autospawns PA during/before PA-start
desktop file is processed.

> > Another possible problem is when PA daemon crashes by some reason and
> > ALSA-pulse app is started just after it.
> 
> That shouldn't generally be a problem. We should autospawn in that case.
> That said, I'm not sure if there is a sequence of precise timings that
> would cause a problem here?
> 
> >>  2. If a given user does not want to use PA, but the system is
> >> configured to run PA, then that user will typically have a PA daemon
> >> started anyway via XDG autostart, unless they have specifically chosen
> >> via their DE to override this startup option. In this scenario, PA is
> >> running already and the automatic fallback stuff in the alsa-plugin
> >> won't work as intended.
> > 
> > XDG isn't used in every environment.  Many window managers won't use
> > it.  So, there are two cases: 2a) PA starts up via XDG but user
> > doesn't want to use.  2b) PA doesn't start up and user doesn't want to
> > use PA.
> 
> Well GNOME and KDE do and there are xdg compliance wrappers for others
> too, so I wouldn't worry about the cases where it's not present (at
> least for this example).

Oh no, you just ignore the cases without XDG.  There are many people
who don't use XDG startup at all (including me), who are using a
light-weight WM like fluxbox, icewm or whatever.  The fallback
mechanism is really for this case.

> We have to deal with the "fallout" when it is
> present. i.e. the 2a).

The case 2a is that user needs manual adjustment anyway.  If XDG is
used, the adjustment is unavoidable.  So, the only sane solution for
this is a static configuration.

But case 2b is different.  The system doesn't start PA, and thus you
assume you don't use PA.  But, then ALSA-native app starts PA because
of the pulse plugin.  This is what annoys most people.


> >>  3. If the system is not configured for PA but a given user does want to
> >> use it, then the system will not run PA at login (due to hacks on the
> >> XDG startup scripts and by setting autospawn=no in the
> >> /etc/pulse/client.conf file), and thus the user will have to find a way
> >> to start pulseaudio themselves (e.g. by copying the client.conf to their
> >> own directory and setting autospawn=yes).
> > 
> > Right.
> > 
> >> So these are the three scenarios we want to cover right?
> >>
> >> If so, automatic systems are not really useful. In order for things to
> >> work right, we really need to prevent both autospawn and manual XDG
> >> spawn easily, both on a global and on a per-user basis.
> >>
> >>> Actually, other apps supporting PA seem doing the same thing already.
> >>> It falls back to other backends when PA connection failed.
> >>
> >> This is true. You make a valid argument. I seem to be judging a alsa
> >> client app in a different way to these other apps with specific PA
> >> support + a fallback scheme for some reason. Not sure why I'm doing
> >> that, but I suspect it relates to the "alsa fallback" in 99% of those
> >> apps will be pure alsa, not automatic-fallback-alsa.
> >>
> >> If you consider a setup whereby we have the following setup:
> >>
> >>  1. autospawn=yes in global client.conf + no local client.conf
> >>  2. enable=no in global daemon.conf + no local daemon.conf
> >>
> >>
> >> The "enable" option is mythical - I've made it up, but it could be added.
> >>
> >>
> >> If a client app that supports PA and has fallback to alsa, this is how
> >> things would work:
> >>
> >>  1. App tries Pulse.
> >>  2. PA is not running, so libpulse tries autospawn.
> >>  3. Autospawn fails (daemon exits due to enable=no config option)
> >>  4. App determins Pulse is not available.
> >>  5. App fallsback to ALSA
> >>  6. ALSA tries Pulse.
> >>  7. PA is not running, so libpulse tries autospawn.
> >>  8. Autospawn fails (daemon exits due to enable=no config option)
> >>  9. ALSA determins Pulse is not available.
> >>  10. ALSA falls back to sysdefault.
> >>  11. Whatever happens next....
> >>
> >>
> >> So as you can see with the automatic system, we have the unnecessary
> >> overhead of starting up twice.
> > 
> > When the fallback is set, it passes PA_CONTEXT_NOAUTOSPAWN, so steps
> > 2-8 will be skipped, thus no big problem here.
> 
> I think you misunderstand. libalsa only tries pulse in step 6. libalsa
> has not had a lookin in the app until step 6, so there is no way
> anything in alsa or alsa-plugins could affect steps 1 through 6.

Ah, I see.

> Remember this is an app that supports "PA natively + ALSA fallback" -
> i.e. there are *two* layers of fallback in this case. That's what I'd
> like to avoid.
> 
> HOwever, I can see steps 7-8 not being required.
> 
> > The problem by fallback is that the autospawn isn't triggered -- that
> > is, when ALSA-pulse app is started before PA daemon, it fails.
> > It means that the fallback option assumes that PA daemon is started
> > already in a certain way like XDG.  And the scenario 3 above is a
> > problem, indeed.  (The scenario 1 might have races in exceptional
> > cases, too.)
> 
> Ugg, so it breaks autospawn too :( That *really* sucks. So all it takes
> if for someone to have an aplay startup sound script and it breaks their
> entire setup? :(

Only if the system is supposed to use PA :)
And remember that this is done in the same way like other apps
(e.g. mplayer) with fallback.

> This system is just keeps creating corner cases!!! I really don't like
> it :( For one thing this means you cannot have console alsa apps using
> PA anymore. While I don't personally care about this, we did get quite a
> few complaints about it before autospawn was default. We'll be the ones
> taking the flack for this configuration.

Actually, this is another issue.  People who are working on console
don't want PA in many cases.  But let's stop arguing whether to use PA
or not here.

> >> Now with a static config, this wouldn't happen. Only one attempt would
> >> be made (in the app) and by the time it reaches alsa, it already knows
> >> we do not want to use PA and thus it doesn't even try to connect to PA.
> > 
> > Sure, a static config check can be put in the fallback easily once
> > when defined.
> > 
> >> So going back to my first three scenarios, the only actual case where an
> >> automatic fallback helps is when the user has disabled PA.
> > 
> > Well, it's rather the case 2b above -- for users with a simple / dumb
> > window manager without touching global setups.  They don't set any
> > flags but silently assume that PA isn't used because it's not started
> > manually.
> 
> Just another one of the corner cases I'd very much like to avoid
> 
> >> The rest of
> >> the cases, the user may get some semblence of a working setup but so
> >> many other things would break (e.g. keys for adjusting volume, OSDs
> >> showing volume, panel mixer applets etc) that it is arguably worse to
> >> give them a half working setup.
> > 
> > Yeah, but you can forget about these stuff.  If something doesn't work
> > without PA, it's the system's fault.  The fallback assumes that it
> > would work without PA.
> 
> So you're saying that PA+non-PA should be treated as equal citizens in
> the Desktop Environment. Becasue that's not the case. Both GNOME and KDE
> are both targeting the recommended setup of PA.

Well, the world is neither GNOME nor KDE.  That's the whole point of a
tricky way like fallback.  There are systems without PA, and both PA
and non-PA systems can coexist on a single machine.  It's just a
matter of configuration.

> If you don't use PA,
> then the user certainly gets a second class experience. This is 100%
> intended and isn't going to change.

It doesn't matter whether non-PA is a second class or not.  It's
irrelevant from the discussion here.  The fact is that still many
people want a non-PA system.  A second-class is cheaper, and easier to
manage.  Such people prefer it to too complex system.  This won't be
changed no matter how advertising PA's merit.  So, please accept this
fact, then continue a constructive discussion.

> So you really have to consider these changes very carefully. I will
> fully support and help develop a deterministic system here, but I just
> cannot see any scenario where automatic checks will work reliably and
> deterministically, especially now I learn that autospawn is disabled :(

The autospawn is really a drastic thing.  It can help much but also it
annoys much...

The current fallback mechanism is far from perfect.  It should be
improved.  But please see the key point of it is that the system can 
use the same alsa-lib config for both PA and non-PA cases.  As said,
if we have an easy way to set / check PA's activity, the fallback
check can be replaced in a better & reliable way.

> >> So the case where it really helps is when the user genuinely opts out of
> >> PA. And if they genuinely do opt out, there are several things to do to
> >> make it so anyway (like setting the autospawn to no in client.conf and
> >> disabling the XDG autostart files), that making alsa config "just work"
> >> is really of minimal usefulness.
> >>
> >> So I still maintain that a static config is better for everyone. Make a
> >> standard way to disable PA on a per-user basis, and make the alsa client
> >> config tie into that easily.
> >>
> >> Users who want PA will have breakage when things are broken at the PA
> >> end, but that's likely more useful overall - it means the user will
> >> report a bug and we can fix their setup.
> >>
> >> User just just opt out, will be able to do so in a robust and officially
> >> blessed way that kills of: 1. autospawn, 2. XDG startup, 3. Alsa
> >> configuration all in one go.
> >>
> >> Added to this, the corner cases where automatic fallback would fail are
> >> avoided (and actually it's relatively common for users to use e.g. aplay
> >> or another alsa client with a remote server for testing their PA network
> >> setups and if the audio started coming out locally due to e.g. a
> >> firewall issue, it would be really odd and would then break PA apps due
> >> to the device hogging, so we really do want to cover this)
> > 
> > Yes, I'm for an easy static config per user-basis, too.
> > However, another question is whether user must setup it to enable /
> > disable PA.  In other words, how to detect reliably whether the
> > running DE is supposed to use PA or not.
> > 
> > The current implementation checks PA connection as the indication of
> > PA-usage.  If there is a better way to know, it can be used instead in
> > the plugin.
> 
> 1. Check PA with full autospawn support.
> 2. I'll look at adding some kind of error state into the connection
> stuff in libpulse that would give information about whether or not PA
> should have been used or not, but something stopped us. The following
> scenarios should be covered by this check:
>  a. Attempted to connect to remote daemon, but failed (e.g. due to
> firewall or simply a daemon not running on the remote end).
>  b. No remote config, attempt to run PA (autospawn=yes, enable=yes) but
> PA didn't start.
> 
> Under those two scenarios, you should fail. But if libpulse can somehow
> tell you "no PA is not meant to be used here" (i.e. "no local daemon +
> (autospawn=no || enable=no)") then you can undertake your fallback scheme.
> 
> I think this approach is more robust, and still gives you most of your
> auto-configuration desires.

Yeah, sounds reasonable.

> The user would very much still have to run $something do disable his PA
> if the system uses it (i.e. echo "enable=no" > ~/.pulse/daemon.conf),
> but that is something I think we'd have to live with.

Hm, I guess the point would be how easy you can achieve this.


> >> I really don't think this would work anyway. As I outlined above, if the
> >> user opts out they *have* to touch some things (disabling PA autospawn
> >> and preventing XDG autostart), so I think it's likely worth abandoning
> >> the whole idea of "[not] touching anything".
> > 
> > Well, PA autospawn is a problem, but it happens only after starting an
> > PA-native app.  With the fallback, ALSA-native app won't autospawn.
> > XDG autostart isn't used by many DEs.  So, this use-case isn't so
> > unrealistic at all.
> 
> I think that's very wrong. "ALSA native" shouldn't be considered
> differently to any other pulse client.

No, no, in the case of non-PA use, ALSA-native is no longer pulse
client.  User never thinks of PA.  The fallback is just for that
purpose.

> To do so just breaks many of the
> mechanisms we've specifically spent time and effort on to put in place
> to make things "Just work". This is a massive backwards step to then
> deliberately break these mechanisms :(
> 
> >>> Can we figure out the error reason from PA-lib?  For example, if
> >>> PA-lib returns an error code indicating that PA is disabled, we can
> >>> use a fallback mechanism.  OTOH, if PA's error is because of other
> >>> reasons (e.g. network down), the fallback shouldn't be used.
> >>
> >> Perhaps, we'd likely need to add a new error code or similar for why the
> >> connection failed.
> >>
> >> But I think the only scenario you'd want to cover is if a local PA was
> >> attempted to be spawned and it failed due to the server being disabled
> >> (e.g. by the enable=no flag that I could add) or if autospawning itself
> >> was disabled and no running server was found.
> >>
> >> I will look into doing this, but as mentioned above, I think the user
> >> will still need to do *something* to disable PA, even if the alsa side
> >> of things "just works" when that is the case.
> > 
> > As mentioned, I'm basically for the static-config solution.  It'll
> > cover more completely.  OTOH, there are corner-cases (like the
> > scenario 2b) to consider more...
> 
> 2b is easy. PA autospawn should work and start PA. It's then the same
> case as 2a.

Ah, maybe this is the misunderstanding.  In 2b, you do _not_ want to
use PA.  PA isn't started by XDG, and you want dmix via aplay.

Ideally, for these environment, user should set enable=no or
whatever.  But it's optional unless user starts PA-native apps, as
long as the fallback works, because PA daemon is never triggered.


> The fact it was started by XDG or autospawn should be 100%
> irrelevant to audio apps. It's an implementation detail. Maybe we'll be
> started by systemds session lingering in the future? Who knows. The
> point is that if the system is configured for PA it should use PA.
> 
> I want to avoid all the strange rules. I don't want to have to explain
> to someone on our IRC channel (and believe me, *I'd* be the one getting
> the fallout from this option, not you!) "Oh pulseaudio automatically
> spawns if it's not running except if the app is an alsa app in which
> case it doesn't but only if you've configured your alsa setup that way
> so it really depends" Users don't really want to know *anything* about
> Pulse or ALSA. They shouldn't care, they just want a system that works.
> and I don't want to have to jump through hoops to do it.
> 
> I will help get the necessary info from libpulse about how to proceed,
> but only after 1.0 is out the door (which should be soon). All I ask is
> that you try to appreciate my concerns here and how there are many
> legitimate use cases and operational steps that would be jeopardised by
> the current implementation and do not do a release with the code as it
> currently stands.

Yeah, let's take a bit more deeper look.


thanks,

Takashi

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

Hiya,

[ Cheat note: There are various agreements and disagreements throughout
this reply - I hope I've stated clearly the reasons why I disagree
(quite strongly) with certain elements and I do firmly believe there is
a way to make this all work, but it needs to be done carefully and I
really hope you will not ship a new library/plugins version with this
stuff enabled until the relevant stuff is in place ]


'Twas brillig, and Takashi Iwai at 13/09/11 10:50 did gyre and gimble:

>>> But one problem is that this setup is a global one.  There is no
>>> trivial way for setting up for each user.
>>
>> Yes, I did the same in Mandriva/Mageia, but it's global only. An option
>> to do this officially in PA configs would IMO solve this issue - the PA
>> configs can already be set to global (/etc/pulse/daemon.conf) or local
>> (~/.pulse/daemon.conf), so if that's all we use to define whether or not
>> we want PA, then we should be all set.
> 
> Or, can we introduce an environment variable to indicate globally
> whether the system is supposed to use PA or not explicitly?  It's
> easier than looking through config files.

I don't think an env var makes sense. Think of console logins, we'd have
to push this env var into the bash profile and deal with other shells
too. It's just too much setup and config to implement at a packaging
level IMO.

> Alternatively, if PA-lib provides a simple function to return the
> enablement state, it'd be fine, too.

I think this is better.

>>>> So the problem I have is thus:
>>>>
>>>>  1. If the user wants to use PA and it's configure in the system that
>>>> way, then ALSA (or any other PA client) will autospawn PA if it's not
>>>> running. If that doesn't work, I would prefer that no ALSA-only fallback
>>>> happens as it masks where the real problem lies.
>>>
>>> Right.  In this case, PA should have been started beforehand.  But,
>>> the start-up is always racy, so it might happen that ALSA-pulse app is
>>> kicked off before PA daemon gets started.  This is one possible
>>> problem.
>>
>> I've still not been able to nail down any races but I've had a handful
>> of bug reports that seem to suggest *something* racy is going on. I'll
>> be damned if I can spot it in the code tho'. :(
> 
> I remember vaguely XDG startup conflicts.  There are two startups, one
> for GNOME and one for KDE, and both are started on KDE.  In addition,
> the GNOME login sound might autospawns PA during/before PA-start
> desktop file is processed.

Re the XDGs, there are two; one for X11 generally (all DE's) and one
specifically for KDE. The latter will disappear eventually when I've
managed to rewrite a bunch of stuff.

But these shouldn't cause any conflicts per-se. "pulseaudio --start"
(which is what is used in both script) shouldn't return until PA is
started and ready and it *should* work happily if both are run at the
same time (emphasis on "should" - I'm not going to rule out any bug
there whatsoever. I'll have to inject some delays into it to try and
test some theories here).

But anyway, if PA is autospawned or started by XDG, all scripts should
work fine. If there are races there, then they are just bugs that need
fixing. The general MO is sound.

>>> Another possible problem is when PA daemon crashes by some reason and
>>> ALSA-pulse app is started just after it.
>>
>> That shouldn't generally be a problem. We should autospawn in that case.
>> That said, I'm not sure if there is a sequence of precise timings that
>> would cause a problem here?
>>
>>>>  2. If a given user does not want to use PA, but the system is
>>>> configured to run PA, then that user will typically have a PA daemon
>>>> started anyway via XDG autostart, unless they have specifically chosen
>>>> via their DE to override this startup option. In this scenario, PA is
>>>> running already and the automatic fallback stuff in the alsa-plugin
>>>> won't work as intended.
>>>
>>> XDG isn't used in every environment.  Many window managers won't use
>>> it.  So, there are two cases: 2a) PA starts up via XDG but user
>>> doesn't want to use.  2b) PA doesn't start up and user doesn't want to
>>> use PA.
>>
>> Well GNOME and KDE do and there are xdg compliance wrappers for others
>> too, so I wouldn't worry about the cases where it's not present (at
>> least for this example).
> 
> Oh no, you just ignore the cases without XDG.  There are many people
> who don't use XDG startup at all (including me), who are using a
> light-weight WM like fluxbox, icewm or whatever.  The fallback
> mechanism is really for this case.
> 
>> We have to deal with the "fallout" when it is
>> present. i.e. the 2a).
> 
> The case 2a is that user needs manual adjustment anyway.  If XDG is
> used, the adjustment is unavoidable.  So, the only sane solution for
> this is a static configuration.

I disagree. The fact that XDG doesn't work should be totally irrelevant.
Any solution that works by virtue of XDG not working is fundamentally
broken.

> But case 2b is different.  The system doesn't start PA, and thus you
> assume you don't use PA.  But, then ALSA-native app starts PA because
> of the pulse plugin.  This is what annoys most people.

That's how it should be. They've configured alsa to use the pulse plugin
by default and thus it should start PA if it's not running by default.
Doing anything else is very, very broken. I very strongly oppose this
approach. Very strongly.

The fact that an app is alsa native or PA native should be completely
irrelevant. How is an average user supposed to cope with the differences
between how various apps work in order to understand that behaviour?
It's a very bad idea to behave differently in this way.


>> Remember this is an app that supports "PA natively + ALSA fallback" -
>> i.e. there are *two* layers of fallback in this case. That's what I'd
>> like to avoid.
>>
>> HOwever, I can see steps 7-8 not being required.
>>
>>> The problem by fallback is that the autospawn isn't triggered -- that
>>> is, when ALSA-pulse app is started before PA daemon, it fails.
>>> It means that the fallback option assumes that PA daemon is started
>>> already in a certain way like XDG.  And the scenario 3 above is a
>>> problem, indeed.  (The scenario 1 might have races in exceptional
>>> cases, too.)
>>
>> Ugg, so it breaks autospawn too :( That *really* sucks. So all it takes
>> if for someone to have an aplay startup sound script and it breaks their
>> entire setup? :(
> 
> Only if the system is supposed to use PA :)

Exactly. And using PA is the recommended setup of pretty much every
distro and of the main DEs. I accept that there may be reasons for
people not to do this, but you should not cripple the majority case!!

> And remember that this is done in the same way like other apps
> (e.g. mplayer) with fallback.

I thought that too, but after your last make I realise it's not. If
mplayer uses it's native PA output, then it will autospawn the PA daemon
if needed, but any ALSA-only app will not have this behaviour in the
current setup. This is really wrong and inconsistent. Users need to know
how each and every audio-producing app works in order to understand the
behaviour. That totally sucks.

>> This system is just keeps creating corner cases!!! I really don't like
>> it :( For one thing this means you cannot have console alsa apps using
>> PA anymore. While I don't personally care about this, we did get quite a
>> few complaints about it before autospawn was default. We'll be the ones
>> taking the flack for this configuration.
> 
> Actually, this is another issue.  People who are working on console
> don't want PA in many cases.  But let's stop arguing whether to use PA
> or not here.

Yeah and many do. That's totally not the point tho'. The point is that
I'm all for giving someone an easy way to opt out. The decision is on
their head if they want a sucky desktop experience. But the fact is you
can't give them this choice without actually making it work properly. If
you do a half hearted job, it'll cause a sucky user experience and it'll
cause *me* more support overhead.

>> So you're saying that PA+non-PA should be treated as equal citizens in
>> the Desktop Environment. Becasue that's not the case. Both GNOME and KDE
>> are both targeting the recommended setup of PA.
> 
> Well, the world is neither GNOME nor KDE.  That's the whole point of a
> tricky way like fallback.  There are systems without PA, and both PA
> and non-PA systems can coexist on a single machine.  It's just a
> matter of configuration.
> 
>> If you don't use PA,
>> then the user certainly gets a second class experience. This is 100%
>> intended and isn't going to change.
> 
> It doesn't matter whether non-PA is a second class or not.  It's
> irrelevant from the discussion here.  The fact is that still many
> people want a non-PA system.  A second-class is cheaper, and easier to
> manage.  Such people prefer it to too complex system.  This won't be
> changed no matter how advertising PA's merit.  So, please accept this
> fact, then continue a constructive discussion.

I've never argued the contrary. I'm fully supporting a mechanism to
allow this, even if it will be a degraded experience for the user. Users
who choose this typically have their own good reasons and I'm not going
to analyse the merits of those reasons here. I'm just stating that your
approach is broken with many use cases and you need to understand that
the primary target - the one that should work as smoothly as possible
without any corners - is the PA case. I'm not against giving users a way
to work without PA, but not at the expense of those that do, and not at
the expense of extra support burden for me.

>> So you really have to consider these changes very carefully. I will
>> fully support and help develop a deterministic system here, but I just
>> cannot see any scenario where automatic checks will work reliably and
>> deterministically, especially now I learn that autospawn is disabled :(
> 
> The autospawn is really a drastic thing.  It can help much but also it
> annoys much...
> 
> The current fallback mechanism is far from perfect.  It should be
> improved.  But please see the key point of it is that the system can 
> use the same alsa-lib config for both PA and non-PA cases.  As said,
> if we have an easy way to set / check PA's activity, the fallback
> check can be replaced in a better & reliable way.

I'll certainly look into this, but as I asked before, please do not ship
this as is.


>> 1. Check PA with full autospawn support.
>> 2. I'll look at adding some kind of error state into the connection
>> stuff in libpulse that would give information about whether or not PA
>> should have been used or not, but something stopped us. The following
>> scenarios should be covered by this check:
>>  a. Attempted to connect to remote daemon, but failed (e.g. due to
>> firewall or simply a daemon not running on the remote end).
>>  b. No remote config, attempt to run PA (autospawn=yes, enable=yes) but
>> PA didn't start.
>>
>> Under those two scenarios, you should fail. But if libpulse can somehow
>> tell you "no PA is not meant to be used here" (i.e. "no local daemon +
>> (autospawn=no || enable=no)") then you can undertake your fallback scheme.
>>
>> I think this approach is more robust, and still gives you most of your
>> auto-configuration desires.
> 
> Yeah, sounds reasonable.

Good :)

>> The user would very much still have to run $something do disable his PA
>> if the system uses it (i.e. echo "enable=no" > ~/.pulse/daemon.conf),
>> but that is something I think we'd have to live with.
> 
> Hm, I guess the point would be how easy you can achieve this.

As well as the config file we could have a PULSEAUDIO_ENABLE=0 env var.
If not present or non-zero PA works, otherwise it doesn't.

That way people could just define an export in their ~/.bashrc. Not sure
if that's better or worse however than the variable in the config file,
but I'm trying to think of ways to make it easy for the user to opt out.

>>>> I really don't think this would work anyway. As I outlined above, if the
>>>> user opts out they *have* to touch some things (disabling PA autospawn
>>>> and preventing XDG autostart), so I think it's likely worth abandoning
>>>> the whole idea of "[not] touching anything".
>>>
>>> Well, PA autospawn is a problem, but it happens only after starting an
>>> PA-native app.  With the fallback, ALSA-native app won't autospawn.
>>> XDG autostart isn't used by many DEs.  So, this use-case isn't so
>>> unrealistic at all.
>>
>> I think that's very wrong. "ALSA native" shouldn't be considered
>> differently to any other pulse client.
> 
> No, no, in the case of non-PA use, ALSA-native is no longer pulse
> client.  User never thinks of PA.  The fallback is just for that
> purpose.

But before you check for PA, you don't know whether you are a pulse
client or not, so defining the env var to prevent autospawning you are
making a concious decision to *favour* the non-PA case. Unsurprisingly,
I've very against this. I'd rather alsa clients were good pulse clients
and played the game. Sure we can offer a mechanism to opt out, but don't
degrade the experience for people who are opting in!!!


>> 2b is easy. PA autospawn should work and start PA. It's then the same
>> case as 2a.
> 
> Ah, maybe this is the misunderstanding.  In 2b, you do _not_ want to
> use PA.  PA isn't started by XDG, and you want dmix via aplay.

No. There is nothing in the 2b case that specifically says you do not
want to use PA. It's just that XDG has failed. That's totally irrelevant
to the question of "Does the user want to use PA?".

So 2b == 2a. The fact that PA was not started by XDG is NOT considered
in anyway a fatal error by libpulse. That's why it has autospawn
support. It's specifically designed to deal with this scenario. Please
do not break it.

> Ideally, for these environment, user should set enable=no or
> whatever.  But it's optional unless user starts PA-native apps, as
> long as the fallback works, because PA daemon is never triggered.

Nope, I could not disagree with this statement more. A failure of XDG
does not indicate that the user does not want PA. We need a more
deterministic system to deal with user choices, this is simply a valid
case for PA to autospawn and you're current approach breaks this
specific implementation.



>> The fact it was started by XDG or autospawn should be 100%
>> irrelevant to audio apps. It's an implementation detail. Maybe we'll be
>> started by systemds session lingering in the future? Who knows. The
>> point is that if the system is configured for PA it should use PA.
>>
>> I want to avoid all the strange rules. I don't want to have to explain
>> to someone on our IRC channel (and believe me, *I'd* be the one getting
>> the fallout from this option, not you!) "Oh pulseaudio automatically
>> spawns if it's not running except if the app is an alsa app in which
>> case it doesn't but only if you've configured your alsa setup that way
>> so it really depends" Users don't really want to know *anything* about
>> Pulse or ALSA. They shouldn't care, they just want a system that works.
>> and I don't want to have to jump through hoops to do it.
>>
>> I will help get the necessary info from libpulse about how to proceed,
>> but only after 1.0 is out the door (which should be soon). All I ask is
>> that you try to appreciate my concerns here and how there are many
>> legitimate use cases and operational steps that would be jeopardised by
>> the current implementation and do not do a release with the code as it
>> currently stands.
> 
> Yeah, let's take a bit more deeper look.

Agreed!

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

At Tue, 13 Sep 2011 12:00:20 +0100,
Hi,

just a few comments to correct the misunderstanding...

Colin Guthrie wrote:
> 
> >>> But one problem is that this setup is a global one.  There is no
> >>> trivial way for setting up for each user.
> >>
> >> Yes, I did the same in Mandriva/Mageia, but it's global only. An option
> >> to do this officially in PA configs would IMO solve this issue - the PA
> >> configs can already be set to global (/etc/pulse/daemon.conf) or local
> >> (~/.pulse/daemon.conf), so if that's all we use to define whether or not
> >> we want PA, then we should be all set.
> > 
> > Or, can we introduce an environment variable to indicate globally
> > whether the system is supposed to use PA or not explicitly?  It's
> > easier than looking through config files.
> 
> I don't think an env var makes sense. Think of console logins, we'd have
> to push this env var into the bash profile and deal with other shells
> too. It's just too much setup and config to implement at a packaging
> level IMO.
> 
> > Alternatively, if PA-lib provides a simple function to return the
> > enablement state, it'd be fine, too.
> 
> I think this is better.

OK.  In either way, I don't mind.  Just a simple way to identify
the thing would be needed.


> >>>>  2. If a given user does not want to use PA, but the system is
> >>>> configured to run PA, then that user will typically have a PA daemon
> >>>> started anyway via XDG autostart, unless they have specifically chosen
> >>>> via their DE to override this startup option. In this scenario, PA is
> >>>> running already and the automatic fallback stuff in the alsa-plugin
> >>>> won't work as intended.
> >>>
> >>> XDG isn't used in every environment.  Many window managers won't use
> >>> it.  So, there are two cases: 2a) PA starts up via XDG but user
> >>> doesn't want to use.  2b) PA doesn't start up and user doesn't want to
> >>> use PA.
> >>
> >> Well GNOME and KDE do and there are xdg compliance wrappers for others
> >> too, so I wouldn't worry about the cases where it's not present (at
> >> least for this example).
> > 
> > Oh no, you just ignore the cases without XDG.  There are many people
> > who don't use XDG startup at all (including me), who are using a
> > light-weight WM like fluxbox, icewm or whatever.  The fallback
> > mechanism is really for this case.
> > 
> >> We have to deal with the "fallout" when it is
> >> present. i.e. the 2a).
> > 
> > The case 2a is that user needs manual adjustment anyway.  If XDG is
> > used, the adjustment is unavoidable.  So, the only sane solution for
> > this is a static configuration.
> 
> I disagree. The fact that XDG doesn't work should be totally irrelevant.
> Any solution that works by virtue of XDG not working is fundamentally
> broken.

Err, sorry, you are screwing up the argument.
Both 2a and 2b are cases where user don't want PA.  It's the
assumption.  The only difference is that 2a is with XDG while 2b is
without XDG.

The case without XDG but user wants PA would be (if any) case 1b.
And obviously the current fallback doesn't fit with this, of course. 


> >> Remember this is an app that supports "PA natively + ALSA fallback" -
> >> i.e. there are *two* layers of fallback in this case. That's what I'd
> >> like to avoid.
> >>
> >> HOwever, I can see steps 7-8 not being required.
> >>
> >>> The problem by fallback is that the autospawn isn't triggered -- that
> >>> is, when ALSA-pulse app is started before PA daemon, it fails.
> >>> It means that the fallback option assumes that PA daemon is started
> >>> already in a certain way like XDG.  And the scenario 3 above is a
> >>> problem, indeed.  (The scenario 1 might have races in exceptional
> >>> cases, too.)
> >>
> >> Ugg, so it breaks autospawn too :( That *really* sucks. So all it takes
> >> if for someone to have an aplay startup sound script and it breaks their
> >> entire setup? :(
> > 
> > Only if the system is supposed to use PA :)
> 
> Exactly. And using PA is the recommended setup of pretty much every
> distro and of the main DEs. I accept that there may be reasons for
> people not to do this, but you should not cripple the majority case!!
> 
> > And remember that this is done in the same way like other apps
> > (e.g. mplayer) with fallback.
> 
> I thought that too, but after your last make I realise it's not. If
> mplayer uses it's native PA output, then it will autospawn the PA daemon
> if needed, but any ALSA-only app will not have this behaviour in the
> current setup. This is really wrong and inconsistent. Users need to know
> how each and every audio-producing app works in order to understand the
> behaviour. That totally sucks.

Hm, maybe I was misinformed then.  But there seem other apps doing
that, too (that's how I was told about NOAUTOSPAWN flag).


> >> This system is just keeps creating corner cases!!! I really don't like
> >> it :( For one thing this means you cannot have console alsa apps using
> >> PA anymore. While I don't personally care about this, we did get quite a
> >> few complaints about it before autospawn was default. We'll be the ones
> >> taking the flack for this configuration.
> > 
> > Actually, this is another issue.  People who are working on console
> > don't want PA in many cases.  But let's stop arguing whether to use PA
> > or not here.
> 
> Yeah and many do. That's totally not the point tho'. The point is that
> I'm all for giving someone an easy way to opt out. The decision is on
> their head if they want a sucky desktop experience. But the fact is you
> can't give them this choice without actually making it work properly. If
> you do a half hearted job, it'll cause a sucky user experience and it'll
> cause *me* more support overhead.
> 
> >> So you're saying that PA+non-PA should be treated as equal citizens in
> >> the Desktop Environment. Becasue that's not the case. Both GNOME and KDE
> >> are both targeting the recommended setup of PA.
> > 
> > Well, the world is neither GNOME nor KDE.  That's the whole point of a
> > tricky way like fallback.  There are systems without PA, and both PA
> > and non-PA systems can coexist on a single machine.  It's just a
> > matter of configuration.
> > 
> >> If you don't use PA,
> >> then the user certainly gets a second class experience. This is 100%
> >> intended and isn't going to change.
> > 
> > It doesn't matter whether non-PA is a second class or not.  It's
> > irrelevant from the discussion here.  The fact is that still many
> > people want a non-PA system.  A second-class is cheaper, and easier to
> > manage.  Such people prefer it to too complex system.  This won't be
> > changed no matter how advertising PA's merit.  So, please accept this
> > fact, then continue a constructive discussion.
> 
> I've never argued the contrary. I'm fully supporting a mechanism to
> allow this, even if it will be a degraded experience for the user. Users
> who choose this typically have their own good reasons and I'm not going
> to analyse the merits of those reasons here. I'm just stating that your
> approach is broken with many use cases and you need to understand that
> the primary target - the one that should work as smoothly as possible
> without any corners - is the PA case. I'm not against giving users a way
> to work without PA, but not at the expense of those that do, and not at
> the expense of extra support burden for me.

Yeah, I do understand it.  But try to look to another side: what if a
non-PA system doesn't work any more smoothly suddenly after installing
pulseaudio package but without touching anything else?  This is the
problem I've seen and we are trying to solve.

So, this is partly a problem of packaging.  Installing a package may
break other environments, but it shouldn't happen brutally.  We'd need
to provide a good way to give the coexistence of both PA and non-PA
systems.


> >> So you really have to consider these changes very carefully. I will
> >> fully support and help develop a deterministic system here, but I just
> >> cannot see any scenario where automatic checks will work reliably and
> >> deterministically, especially now I learn that autospawn is disabled :(
> > 
> > The autospawn is really a drastic thing.  It can help much but also it
> > annoys much...
> > 
> > The current fallback mechanism is far from perfect.  It should be
> > improved.  But please see the key point of it is that the system can 
> > use the same alsa-lib config for both PA and non-PA cases.  As said,
> > if we have an easy way to set / check PA's activity, the fallback
> > check can be replaced in a better & reliable way.
> 
> I'll certainly look into this, but as I asked before, please do not ship
> this as is.

Yeah, I'm considering either changing or reverting it, but let me do
it later (I'm in a conference for a couple of days).


> >> 1. Check PA with full autospawn support.
> >> 2. I'll look at adding some kind of error state into the connection
> >> stuff in libpulse that would give information about whether or not PA
> >> should have been used or not, but something stopped us. The following
> >> scenarios should be covered by this check:
> >>  a. Attempted to connect to remote daemon, but failed (e.g. due to
> >> firewall or simply a daemon not running on the remote end).
> >>  b. No remote config, attempt to run PA (autospawn=yes, enable=yes) but
> >> PA didn't start.
> >>
> >> Under those two scenarios, you should fail. But if libpulse can somehow
> >> tell you "no PA is not meant to be used here" (i.e. "no local daemon +
> >> (autospawn=no || enable=no)") then you can undertake your fallback scheme.
> >>
> >> I think this approach is more robust, and still gives you most of your
> >> auto-configuration desires.
> > 
> > Yeah, sounds reasonable.
> 
> Good :)
> 
> >> The user would very much still have to run $something do disable his PA
> >> if the system uses it (i.e. echo "enable=no" > ~/.pulse/daemon.conf),
> >> but that is something I think we'd have to live with.
> > 
> > Hm, I guess the point would be how easy you can achieve this.
> 
> As well as the config file we could have a PULSEAUDIO_ENABLE=0 env var.
> If not present or non-zero PA works, otherwise it doesn't.

Yes, it's the very similar thing I've thought of, too.

> That way people could just define an export in their ~/.bashrc. Not sure
> if that's better or worse however than the variable in the config file,
> but I'm trying to think of ways to make it easy for the user to opt out.

OK, great.

> >>>> I really don't think this would work anyway. As I outlined above, if the
> >>>> user opts out they *have* to touch some things (disabling PA autospawn
> >>>> and preventing XDG autostart), so I think it's likely worth abandoning
> >>>> the whole idea of "[not] touching anything".
> >>>
> >>> Well, PA autospawn is a problem, but it happens only after starting an
> >>> PA-native app.  With the fallback, ALSA-native app won't autospawn.
> >>> XDG autostart isn't used by many DEs.  So, this use-case isn't so
> >>> unrealistic at all.
> >>
> >> I think that's very wrong. "ALSA native" shouldn't be considered
> >> differently to any other pulse client.
> > 
> > No, no, in the case of non-PA use, ALSA-native is no longer pulse
> > client.  User never thinks of PA.  The fallback is just for that
> > purpose.
> 
> But before you check for PA, you don't know whether you are a pulse
> client or not, so defining the env var to prevent autospawning you are
> making a concious decision to *favour* the non-PA case. Unsurprisingly,
> I've very against this. I'd rather alsa clients were good pulse clients
> and played the game. Sure we can offer a mechanism to opt out, but don't
> degrade the experience for people who are opting in!!!

Well, again, if a good mechanism is introduced to identify the use of
PA, the things gets really easier.  I'm not stuck with the current
fallback mechanism at all.  But some automatic way to route either PA
or non-PA plugin is needed.  Otherwise user would need to re-define
the asoundrc by himself, and it's a bigger burden, especially when you
think of cryptical syntax of asoundrc.


thanks,

Takashi

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

'Twas brillig, and Takashi Iwai at 13/09/11 13:18 did gyre and gimble:

>>>> We have to deal with the "fallout" when it is
>>>> present. i.e. the 2a).
>>>
>>> The case 2a is that user needs manual adjustment anyway.  If XDG is
>>> used, the adjustment is unavoidable.  So, the only sane solution for
>>> this is a static configuration.
>>
>> I disagree. The fact that XDG doesn't work should be totally irrelevant.
>> Any solution that works by virtue of XDG not working is fundamentally
>> broken.
> 
> Err, sorry, you are screwing up the argument.
> Both 2a and 2b are cases where user don't want PA.  It's the
> assumption.  The only difference is that 2a is with XDG while 2b is
> without XDG.

OK, so perhaps 2a and 2b are cases where the user doesn't want to use
PA, but then there are corresponding cases where the user *does* want to
use PA. I need the 2b case where the user does want to use PA to work
smoothly and with your current approach it does not.

I'm trying to consider all cases, both with and without PA running and
both with and without PA being desired. I wasn't clear in the previous
point tho', so I apologise.

> The case without XDG but user wants PA would be (if any) case 1b.
> And obviously the current fallback doesn't fit with this, of course. 

Yeah, sorry I probably should have reworded things to related it to 1b
instead. Sorry. As you say the principle is still valid tho'.


>> I thought that too, but after your last make I realise it's not. If
>> mplayer uses it's native PA output, then it will autospawn the PA daemon
>> if needed, but any ALSA-only app will not have this behaviour in the
>> current setup. This is really wrong and inconsistent. Users need to know
>> how each and every audio-producing app works in order to understand the
>> behaviour. That totally sucks.
> 
> Hm, maybe I was misinformed then.  But there seem other apps doing
> that, too (that's how I was told about NOAUTOSPAWN flag).

Can you let me know which apps? Defining NOAUTOSPAWN when using the alsa
mode *after* using the PA-native mode is something I have no problem
with (we've tried PA and it doesn't work so no use in ALSA trying to
autospawn PA too), but defining it before using PA-native mode or when
only alsa mode is available is a pretty bad idea and should be fixed.


>> I've never argued the contrary. I'm fully supporting a mechanism to
>> allow this, even if it will be a degraded experience for the user. Users
>> who choose this typically have their own good reasons and I'm not going
>> to analyse the merits of those reasons here. I'm just stating that your
>> approach is broken with many use cases and you need to understand that
>> the primary target - the one that should work as smoothly as possible
>> without any corners - is the PA case. I'm not against giving users a way
>> to work without PA, but not at the expense of those that do, and not at
>> the expense of extra support burden for me.
> 
> Yeah, I do understand it.  But try to look to another side: what if a
> non-PA system doesn't work any more smoothly suddenly after installing
> pulseaudio package but without touching anything else?  This is the
> problem I've seen and we are trying to solve.

I don't think papering over the cracks with work arounds is the right
approach in this scenario. The user may get the mistaken impression that
all is well simply because they can hear sound but then get all confused
as to why his DE doesn't offer him a mixer to control volume and why his
bluetooth headset doesn't just magically work with Skype etc. I think if
the user has opted to use PA and something breaks, then the user should
be told about it quite obviously and then they can take appropriate
action, not limp on with an incomplete setup.

> So, this is partly a problem of packaging.  Installing a package may
> break other environments, but it shouldn't happen brutally.  We'd need
> to provide a good way to give the coexistence of both PA and non-PA
> systems.

I agree with the "good way to.." bit, but I actually disagree about the
brutality :p I think I've voiced that sufficiently in the above segment
tho'.

>>> The current fallback mechanism is far from perfect.  It should be
>>> improved.  But please see the key point of it is that the system can 
>>> use the same alsa-lib config for both PA and non-PA cases.  As said,
>>> if we have an easy way to set / check PA's activity, the fallback
>>> check can be replaced in a better & reliable way.
>>
>> I'll certainly look into this, but as I asked before, please do not ship
>> this as is.
> 
> Yeah, I'm considering either changing or reverting it, but let me do
> it later (I'm in a conference for a couple of days).

Awesome thanks. I'll put this at the top of my list before any of the
fun things after we get 1.0 out the way :)


> Well, again, if a good mechanism is introduced to identify the use of
> PA, the things gets really easier.  I'm not stuck with the current
> fallback mechanism at all.  But some automatic way to route either PA
> or non-PA plugin is needed.  Otherwise user would need to re-define
> the asoundrc by himself, and it's a bigger burden, especially when you
> think of cryptical syntax of asoundrc.

Yeah I think this is the crux of it all. When we have this I'll have a
much better case for convincing of any points we disagree on :D

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Arun Raghavan]

On Tue, 2011-09-13 at 09:55 +0200, Takashi Iwai wrote:
> > So the problem I have is thus:
> > 
> >  1. If the user wants to use PA and it's configure in the system
> that
> > way, then ALSA (or any other PA client) will autospawn PA if it's
> not
> > running. If that doesn't work, I would prefer that no ALSA-only
> fallback
> > happens as it masks where the real problem lies.
> 
> Right.  In this case, PA should have been started beforehand.  But,
> the start-up is always racy, so it might happen that ALSA-pulse app is
> kicked off before PA daemon gets started.  This is one possible
> problem.
> 
> Another possible problem is when PA daemon crashes by some reason and
> ALSA-pulse app is started just after it.

I don't think this is a case that we should plan or design for. It's an
outlier, and pretending to work seamlessly when the underlying system
breaks is just going to make it harder to fix problems.

Extending this as a general comment -- I think it's bad to try to
fallback to ALSA in any case if PulseAudio isn't functioning properly.
We got to the currently decent shape we're in by refusing to take that
route and IMO we should continue doing so until there's nothing left to
fix. :)

> >  2. If a given user does not want to use PA, but the system is
> > configured to run PA, then that user will typically have a PA daemon
> > started anyway via XDG autostart, unless they have specifically
> chosen
> > via their DE to override this startup option. In this scenario, PA
> is
> > running already and the automatic fallback stuff in the alsa-plugin
> > won't work as intended.
> 
> XDG isn't used in every environment.  Many window managers won't use
> it.  So, there are two cases: 2a) PA starts up via XDG but user
> doesn't want to use.  2b) PA doesn't start up and user doesn't want to
> use PA.
> 
> >  3. If the system is not configured for PA but a given user does
> want to
> > use it, then the system will not run PA at login (due to hacks on
> the
> > XDG startup scripts and by setting autospawn=no in the
> > /etc/pulse/client.conf file), and thus the user will have to find a
> way
> > to start pulseaudio themselves (e.g. by copying the client.conf to
> their
> > own directory and setting autospawn=yes).
> 
> Right. 

So, summarising the thread so far, we should standardise how PA is
disabled in config (daemon.conf option to add "enabled = no" sounds good
to me) and have clients call some libpulse API to check whether PA is
enabled or not. The alsa pulse plugin should fallback *only* if PA has
specifically been disabled (not if PA failed to start up for some reason
-- that's a bug we need to resolve). This will give per-user control
over PA being enabled/disabled which was the original use-case.

I've summarised this in the hope that we can convert the thread into "we
need to do this in alsa-* and this in pulse*" and then get it done. It's
a long thread, and some of the corner cases are subtle, so feel free to
point out if something isn't clear or not covered.

Regards,
Arun

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[David Henningsson]

On 09/13/2011 10:47 AM, Colin Guthrie wrote:
> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>>> Yup I think so. I'll put this on my list (I did try and suggest
>>> something like this a while back, but got little in the way of responses
>>> - I wanted to standardise things rather than have distro hacks
>>> everywhere - can't seem to find the email now, so I'll just resend it
>>> when I have some time to think straight)
>>
>> Yeah, we want to have some really easy way to check whether PA is
>> enabled or not.  For example, in the case of X11, you can check
>> $DISPLAY (or options are given explicitly) as a primary check.
>
> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
> example works differently to yours. (Disclaimer, I've already said I
> think this is ugly). It works by altering the config file dynamically
> such that the default is either dmix or pulse depending on whether PA is
> running. Of course "PA is running" is a broken check in the first place
> (see the "ugly" word in my disclaimer!) as we could be dealing with thin
> clients and remote PA daemons only, in which case there is no running
> PA.

I think adding a function in libpulse named is_PA_enabled() makes sense, 
as discussed somewhere else in this thread. Once we have that, we should 
change "PA is running" to "file_exists(libpulse.so.x) && 
dlopen(libpulse.so.x) && is_PA_enabled()". Does that seem to be a 
reasonable solution?

Then the PulseAudio side of things can decide how to determine the 
result value of is_PA_enabled() - environment variables, client.conf and 
all that.

Other than that I haven't studied the current sysdefault proposal in 
detail, but the general comment is that the sound system configuration 
in Linux is complex enough :-)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

'Twas brillig, and David Henningsson at 14/09/11 10:51 did gyre and gimble:
> On 09/13/2011 10:47 AM, Colin Guthrie wrote:
>> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>>>> Yup I think so. I'll put this on my list (I did try and suggest
>>>> something like this a while back, but got little in the way of
>>>> responses
>>>> - I wanted to standardise things rather than have distro hacks
>>>> everywhere - can't seem to find the email now, so I'll just resend it
>>>> when I have some time to think straight)
>>>
>>> Yeah, we want to have some really easy way to check whether PA is
>>> enabled or not.  For example, in the case of X11, you can check
>>> $DISPLAY (or options are given explicitly) as a primary check.
>>
>> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
>> example works differently to yours. (Disclaimer, I've already said I
>> think this is ugly). It works by altering the config file dynamically
>> such that the default is either dmix or pulse depending on whether PA is
>> running. Of course "PA is running" is a broken check in the first place
>> (see the "ugly" word in my disclaimer!) as we could be dealing with thin
>> clients and remote PA daemons only, in which case there is no running
>> PA.
> 
> I think adding a function in libpulse named is_PA_enabled() makes sense,
> as discussed somewhere else in this thread. Once we have that, we should
> change "PA is running" to "file_exists(libpulse.so.x) &&
> dlopen(libpulse.so.x) && is_PA_enabled()". Does that seem to be a
> reasonable solution?

It depends on how clever the check is.


I've maintained that we need to connect to check (mainly due to remote
connections), but in actual fact the check could just be:

bool is_PA_enabled()
{
 if (local && (!daemon_binary_exists || conf->enabled=="no"))
 	return false;
 return true;
}

If the user has managed to run PA daemon (e.g. it's running from before
the config was changed to set enabled=no) then we still won't use it, so
a "connection check" isn't really needed.

And if the connection is refused or it doesn't autospawn, that's just an
error we want to see and we wouldn't process a fallback in that case anyway.

So actually this check could be pretty simply defined as that.

The only slight "boundary" that is crossed here is the parsing of the
daemon config from the client library... which is a bit wrong, but I
think somewhat justified.

If it's genuinely ugly to check the daemon.conf in the client, we could
just process the autospwan and check the daemon return value (with a
specific return value meaning - "I'm disabled") and get the same result
so either way, this approach should work I think.



Of course the "local" check is a bit complicated as we can have multiple
strings defined in the server config and the first one in the list is
always our local one:

e.g. here I have:
{6cb2a4b2bd6df042e57da8a4000001d4}unix:/home/colin/.pulse/6cb2a4b2bd6df042e57da8a4000001d4-runtime/native
tcp:jimmy:4713 tcp6:jimmy:4713

So for the "local" check to succeed the first entry in that string has
to be a local socket that machines our current dbus machine id.

Anything else and we consider ourselves as having a non-local connection
and PA should be used. Of course if the server config is totally empty,
that's also considered local.


Does this work?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[David Henningsson]

On 09/14/2011 12:35 PM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 14/09/11 10:51 did gyre and gimble:
>> On 09/13/2011 10:47 AM, Colin Guthrie wrote:
>>> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>>>>> Yup I think so. I'll put this on my list (I did try and suggest
>>>>> something like this a while back, but got little in the way of
>>>>> responses
>>>>> - I wanted to standardise things rather than have distro hacks
>>>>> everywhere - can't seem to find the email now, so I'll just resend it
>>>>> when I have some time to think straight)
>>>>
>>>> Yeah, we want to have some really easy way to check whether PA is
>>>> enabled or not.  For example, in the case of X11, you can check
>>>> $DISPLAY (or options are given explicitly) as a primary check.
>>>
>>> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
>>> example works differently to yours. (Disclaimer, I've already said I
>>> think this is ugly). It works by altering the config file dynamically
>>> such that the default is either dmix or pulse depending on whether PA is
>>> running. Of course "PA is running" is a broken check in the first place
>>> (see the "ugly" word in my disclaimer!) as we could be dealing with thin
>>> clients and remote PA daemons only, in which case there is no running
>>> PA.
>>
>> I think adding a function in libpulse named is_PA_enabled() makes sense,
>> as discussed somewhere else in this thread. Once we have that, we should
>> change "PA is running" to "file_exists(libpulse.so.x)&&
>> dlopen(libpulse.so.x)&&  is_PA_enabled()". Does that seem to be a
>> reasonable solution?
>
> It depends on how clever the check is.

That would be an PulseAudio internal problem, I assume - i e, it is up 
to PulseAudio to make that check clever enough, or face the wrath of 
ugly workarounds ;-)

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Colin Guthrie]

'Twas brillig, and David Henningsson at 14/09/11 11:50 did gyre and gimble:
> On 09/14/2011 12:35 PM, Colin Guthrie wrote:
>> 'Twas brillig, and David Henningsson at 14/09/11 10:51 did gyre and
>> gimble:
>>> On 09/13/2011 10:47 AM, Colin Guthrie wrote:
>>>> 'Twas brillig, and Takashi Iwai at 13/09/11 08:55 did gyre and gimble:
>>>>>> Yup I think so. I'll put this on my list (I did try and suggest
>>>>>> something like this a while back, but got little in the way of
>>>>>> responses
>>>>>> - I wanted to standardise things rather than have distro hacks
>>>>>> everywhere - can't seem to find the email now, so I'll just resend it
>>>>>> when I have some time to think straight)
>>>>>
>>>>> Yeah, we want to have some really easy way to check whether PA is
>>>>> enabled or not.  For example, in the case of X11, you can check
>>>>> $DISPLAY (or options are given explicitly) as a primary check.
>>>>
>>>> Yeah, but sadly I don't think this is possible. The Ubuntu solution for
>>>> example works differently to yours. (Disclaimer, I've already said I
>>>> think this is ugly). It works by altering the config file dynamically
>>>> such that the default is either dmix or pulse depending on whether
>>>> PA is
>>>> running. Of course "PA is running" is a broken check in the first place
>>>> (see the "ugly" word in my disclaimer!) as we could be dealing with
>>>> thin
>>>> clients and remote PA daemons only, in which case there is no running
>>>> PA.
>>>
>>> I think adding a function in libpulse named is_PA_enabled() makes sense,
>>> as discussed somewhere else in this thread. Once we have that, we should
>>> change "PA is running" to "file_exists(libpulse.so.x)&&
>>> dlopen(libpulse.so.x)&&  is_PA_enabled()". Does that seem to be a
>>> reasonable solution?
>>
>> It depends on how clever the check is.
> 
> That would be an PulseAudio internal problem, I assume - i e, it is up
> to PulseAudio to make that check clever enough, or face the wrath of
> ugly workarounds ;-)

Well, my main concern is that we have to be quite certain that we can
make it work without connecting to PA.

Otherwise we may end up connecting twice, once to probe and a second
time for the actual connection.

If it turns out we *have* to try and connect to make the check work
properly, then having a separate API check is unneeded and potentially
unreliable or inefficient.

So perhaps we don't have specific checks, but instead just try and
connect? Maybe that's better overall.

However, I can see the desire and general usefulness of a synchronous
check, so it's quite desirable. We just need to be sure it can be done
(at the moment I think it can, but there are so many corner cases it's
hard to be 100% confident I'm thinking of them all!)

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [PATCH 0/3] Fallback mechanism for pulse plugin

[Raymond Yau]

2011/7/26 Takashi Iwai <tiwai@suse.de>:
> Hi,
>
> the following are experimental patches for implementing the fallback
> option of PCM / control pulse plugin.  When the connection to PA
> server fails, the plugin tries to open the fallback name.
>
> For achieving this, I added the new standard definition "sysdefault",
> which is equal with the normal "default" PCM / control definitions.
> The difference is only the name, i.e. it won't be overridden by other
> setups.  Then two new API functions for opening a fallback PCM /
> control, and finally a patch for pulse-plugin will follow.  All
> changes are relatively small and easy.
>
> Let me know if you have any suggestions or a better idea.
>

if  the definition of sysdefault for pcm is

pcm.sysdefault cards.pcm.default

it seem that definition of sysdefault for ctl should be

ctl.sysdefault ctl.hw


since aplay -Dsysdefault:1 any.wav can select card 1 's default pcm