[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin

Takashi Iwai tiwai at suse.de
Mon Sep 12 11:23:01 CEST 2011

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

> 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

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.



More information about the Alsa-devel mailing list