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

[Takashi Iwai]

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

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


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

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

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

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

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

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

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

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

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

Right.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


thanks,

Takashi