Hi,
'Twas brillig, and Takashi Iwai at 12/09/11 09:05 did gyre and gimble:
At Sat, 03 Sep 2011 17:27:29 +0200, Colin Guthrie wrote:
Hi,
Sorry for the late reply.
And sorry for the late reply to this (as I've been on vacation until today :)
:)
'Twas brillig, and Takashi Iwai at 26/07/11 14:33 did gyre and gimble:
Hi,
the following are experimental patches for implementing the fallback option of PCM / control pulse plugin. When the connection to PA server fails, the plugin tries to open the fallback name.
For achieving this, I added the new standard definition "sysdefault", which is equal with the normal "default" PCM / control definitions. The difference is only the name, i.e. it won't be overridden by other setups. Then two new API functions for opening a fallback PCM / control, and finally a patch for pulse-plugin will follow. All changes are relatively small and easy.
Let me know if you have any suggestions or a better idea.
Personally I don't really like this idea at all.
If the connection fails, then it could hog the device preventing other clients from working correctly.
This could happen e.g. if you do:
PULSE_SERVER=192.168.1.99 aplay some.wav
Here it is quite expected that the connection will fail if the network is down but the last thing I want it to do is to open the local sound device.
In such a case, we can check $PULSE_SERVER in the plugin and disables fallback for remote access.
No, that won't be sufficient, see below.
The same would be true if you SSH'ed to a remote machine, taking the PA connection config with you in the X11 root window PULSE_SERVER property. If the user has not enabled their tcp protocol option or doesn't have the relevant port open on their firewall, then you really don't want them to open the sound device on the remote machine.
So while I can see some use cases for this, I think it would be much better to ensure that if the user wants to use PA, that their asoundrc setup is just configured correctly, not have any kind of automatic fallback.
Sorry, this doesn't work. The problem is that you may have multiple desktop systems on a single machine, one with PA (e.g. GNOME) and one without PA (e.g. for minimalist). Usually a system with PA installed has a global asoundrc hook. Then this blocks the non-PA users. It's why I had to come up with this solution after years struggle to promote PA.
So you're talking about a multi-headed system here with multiple sound cards - separated out for each individual user and allocated to seats by e.g. systemd configuration?
In such a setup, would the user who is not using PA not have to define their own default card anyway so as to use the one they have been assigned (AFAIK, alsa will see all the cards and try to open the first one it finds, not the first one which the current user has ACL access on). PA obviously "Just works"(tm) in these kind of setups as it fully enumerates the devices and ignores completely the ones it does not have ACL access on.
So if the user wants to work in such a multi headed system, with pure-alsa, then they'll have to do some manual setup to pick their default device anyway. In which case this automated fallback is of minimal usefulness practically speaking (assuming I'm correct about the device enumeration stuff in pure alsa).
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.
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.
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.
I have made similar complaints against the approach Ubuntu take here... it's quite different in that they have a dynamic "asoundrc" type config before it even speaks to the module.
In their case there are many corner cases relating to non-local PAs, but in that case the opposite problem is true, i.e. it will NOT use a remote PA if a local one is not running...
If the remote-access is the only problem, it can be checked in the plugin, no?
No, as PA config is not simply PULSE_SERVER env var. It's also the PULSE_SERVER x11 root window property (which allows seamless SSHing to other machines), so the plugin would also have to check that and thus be linked against X11, then you would also have to check the client.conf file both user-specific and systemwise as it too can specify a "default-server" option.
It isn't really practical to duplicate the logic in the plugin, so if this system were to be used, we'd have to provide some kind of config-test binary in PA itself to do the checks needed and you'd have to shell out to it and check the return value or similar.
All in all I think it's just too complex to try and model in an automated way and when it goes wrong, it's really confusing and will be hard to debug.
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).
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?
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.
Col