I've only just noticed that this patch series has already been committed to the tree.
As stated below, I really don't think it's a good idea to activate this. And if it's not activated, are there any other non-PA related cases where this makes sense? If not, perhaps this API should be reverted before an official release if you agree with my comments below.
Col
'Twas brillig, and Colin Guthrie at 03/09/11 16:27 did gyre and gimble:
Hi,
Sorry for the late reply.
'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.
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. 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...
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.
Col