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.
- 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).
- Check PA with full autospawn support.
- 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