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

Mon Sep 12 10:46:19 CEST 2011

Hi,

'Twas brillig, and Takashi Iwai at 12/09/11 09:05 did gyre and gimble:
> 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.

No, that won't be sufficient, see below.

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

So you're talking about a multi-headed system here with multiple sound
cards - separated out for each individual user and allocated to seats by
e.g. systemd configuration?

In such a setup, would the user who is not using PA not have to define
their own default card anyway so as to use the one they have been
assigned (AFAIK, alsa will see all the cards and try to open the first
one it finds, not the first one which the current user has ACL access
on). PA obviously "Just works"(tm) in these kind of setups as it fully
enumerates the devices and ignores completely the ones it does not have
ACL access on.

So if the user wants to work in such a multi headed system, with
pure-alsa, then they'll have to do some manual setup to pick their
default device anyway. In which case this automated fallback is of
minimal usefulness practically speaking (assuming I'm correct about the
device enumeration stuff in pure alsa).

If you are talking about a system whereby several, separate users can
log on to the same seat, but at different times (fast user switching),
then I can see this being more desirable.

That said, I still don't like automated fallbacks. If a user has chosen
to use PA, I firmly believe that's what they should get. It should
fallback under any circumstances as momentary errors could result in
apps being run in an even more unfamiliar setup compounding any
strangeness in the operation of their computer which will lead to more
problems for us upstream.

I would support a static config fallback such that there is a
system-wide and user-specific option that can be turned on/off to say "I
want to use PA", but I really do not want this to be a
try/fail/alternative type system.

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

No, as PA config is not simply PULSE_SERVER env var. It's also the
PULSE_SERVER x11 root window property (which allows seamless SSHing to
other machines), so the plugin would also have to check that and thus be
linked against X11, then you would also have to check the client.conf
file both user-specific and systemwise as it too can specify a
"default-server" option.

It isn't really practical to duplicate the logic in the plugin, so if
this system were to be used, we'd have to provide some kind of
config-test binary in PA itself to do the checks needed and you'd have
to shell out to it and check the return value or similar.

All in all I think it's just too complex to try and model in an
automated way and when it goes wrong, it's really confusing and will be
hard to debug.

As I said above, I'd much rather a system where by we can check for a
known config file (/etc/pulseaudio/daemon.conf
$HOME/.pulseaudio/daemon.conf)? which specifies whether the user wants
to use PulseAudio or not (defaults to true).

I'd even be happy enough to modify PA to not startup when enabled=false
is found in that config file when started explicityly so this would also
take care of not starting the PA daemon for these "opting out user" via
XDG Autostart files which would currently be the case. In case you don't
know, PA will automatically start in an X11 session, so even with this
config in place, there still needs to be a separate configuration step
made for the user to prevent this from happening when they log in. That
problem is not solved by this patch, and in fact, when PA daemon is
started by XDG, the PA daemon is running and thus this the user would
use PA anyway, so it's probably worth thinking about the whole problem
rather than just this part and coming up with a full solution.

All in all, I think a much more holistic solution can be done with a
static config approach - one that works for users both opting in and
opting out and can be much more deterministic, but still give user-level
granularity.

Do you agree?

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

Oh, trust me Ubuntu would likely end up using it by default as their
current hacks are quite similar. It's already annoying enough there.

I think the same usefulness can be achieved with static configs but in a
much more deterministic way and one which doesn't have strange corner cases.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

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/]