[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin
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
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 ]
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
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)
[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);
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" } }
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
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
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
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
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
'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
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:
- 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.
- 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.
- 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:
- autospawn=yes in global client.conf + no local client.conf
- 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:
- App tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- App determins Pulse is not available.
- App fallsback to ALSA
- ALSA tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- ALSA determins Pulse is not available.
- ALSA falls back to sysdefault.
- 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
'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:
- 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?
- 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).
- 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:
- autospawn=yes in global client.conf + no local client.conf
- 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:
- App tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- App determins Pulse is not available.
- App fallsback to ALSA
- ALSA tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- ALSA determins Pulse is not available.
- ALSA falls back to sysdefault.
- 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
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:
- 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?
- 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.
- 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:
- autospawn=yes in global client.conf + no local client.conf
- 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:
- App tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- App determins Pulse is not available.
- App fallsback to ALSA
- ALSA tries Pulse.
- PA is not running, so libpulse tries autospawn.
- Autospawn fails (daemon exits due to enable=no config option)
- ALSA determins Pulse is not available.
- ALSA falls back to sysdefault.
- 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.
- Check PA with full autospawn support.
- 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
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:
- 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?
- 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.
- Check PA with full autospawn support.
- 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
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.
- 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).
- Check PA with full autospawn support.
- 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
'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
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 :-)
'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
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 ;-)
'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
On Tue, 2011-09-13 at 09:55 +0200, Takashi Iwai wrote:
So the problem I have is thus:
- 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. :)
- 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.
- 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
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
participants (5)
-
Arun Raghavan -
Colin Guthrie -
David Henningsson -
Raymond Yau -
Takashi Iwai