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

[Takashi Iwai]

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

just a few comments to correct the misunderstanding...

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

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


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

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

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


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

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


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

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

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


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

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


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

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

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

OK, great.

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

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


thanks,

Takashi