'Twas brillig, and Takashi Iwai at 13/09/11 13:18 did gyre and gimble:
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.
OK, so perhaps 2a and 2b are cases where the user doesn't want to use PA, but then there are corresponding cases where the user *does* want to use PA. I need the 2b case where the user does want to use PA to work smoothly and with your current approach it does not.
I'm trying to consider all cases, both with and without PA running and both with and without PA being desired. I wasn't clear in the previous point tho', so I apologise.
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.
Yeah, sorry I probably should have reworded things to related it to 1b instead. Sorry. As you say the principle is still valid tho'.
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).
Can you let me know which apps? Defining NOAUTOSPAWN when using the alsa mode *after* using the PA-native mode is something I have no problem with (we've tried PA and it doesn't work so no use in ALSA trying to autospawn PA too), but defining it before using PA-native mode or when only alsa mode is available is a pretty bad idea and should be fixed.
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.
I don't think papering over the cracks with work arounds is the right approach in this scenario. The user may get the mistaken impression that all is well simply because they can hear sound but then get all confused as to why his DE doesn't offer him a mixer to control volume and why his bluetooth headset doesn't just magically work with Skype etc. I think if the user has opted to use PA and something breaks, then the user should be told about it quite obviously and then they can take appropriate action, not limp on with an incomplete setup.
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.
I agree with the "good way to.." bit, but I actually disagree about the brutality :p I think I've voiced that sufficiently in the above segment tho'.
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).
Awesome thanks. I'll put this at the top of my list before any of the fun things after we get 1.0 out the way :)
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.
Yeah I think this is the crux of it all. When we have this I'll have a much better case for convincing of any points we disagree on :D
Col