[alsa-devel] [PATCH 0/3] Fallback mechanism for pulse plugin
tiwai at suse.de
Mon Sep 12 10:05:55 CEST 2011
At Sat, 03 Sep 2011 17:27:29 +0200,
Colin Guthrie wrote:
> Sorry for the late reply.
And sorry for the late reply to this (as I've been on vacation until
> '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
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
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
> 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
> 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.
More information about the Alsa-devel