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.
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.
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?
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.
thanks,
Takashi