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

[Colin Guthrie]

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

Very true.

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

Sad, but also very true.


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

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


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

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

So the problem I have is thus:

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

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

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


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

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

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

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

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

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


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


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

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


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


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


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

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

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

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

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

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


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

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

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

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

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

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

Col







-- 

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

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