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

Colin Guthrie gmane at colin.guthr.ie
Sat Sep 3 17:27:29 CEST 2011


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= 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

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.



Colin Guthrie

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

More information about the Alsa-devel mailing list