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