[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin

[Takashi Iwai]

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