--check option seems not to work from su(1) as daemon user

[gdg@xxxxxxxxxx (Glenn Golden)]

Hi Tanu,

OK, next batch of questions pertaining to the Wiki writeup. (Just remember:
I warned you... :) )

Some of these probably seem off-topic relative to runtime dirs and pid files,
but what's happened is that it seems almost impossible to discuss that narrow
topic satisfactorily without also addressing the somewhat larger issue of
"identification", i.e. "Which PA daemon do we really want to be talking to?"

Various entities that care about identification would seem to include:

   * pulseaudio(1) itself: --start, --kill, --check options 
   * pavucontrol
   * pactl
   * pacmd
   * Programs (or humans) that send signals to PADs (PA daemons) for
     control purposes.

And of course, in addition to the above, the audio clients themselves, but that
is surely outside the scope of what I want to write up for the Wiki.

Anyway... it seemed to me like the core of this "identification" question is
a better understanding on my part of the feasible/supported PA topologies,
so that's what most of the questions below relate to.  Here's a list of
possibilities, and my take on each (which may be totally wrong). Please
comment on the reality of these:

   - One user runs a single PAD on local host. [Certain]

   - One user runs multiple PADs on local host. [The doc for --use-pid-file
     implies that this is possible, but haven't been able to get it to work;
     see Q1 and Q3 below.]

   - Multiple users on a given host, each of whom may be running one or more
     PADs on that host. [Think so, not sure.]

   - Single system-wide PAD on a given host. [Certain]

   - Multiple system-wide PADs on a given host. [No clue.]

   - One or more system-wide PADs operating concurrently with one or more
     user PADs. [No clue]

And then, in a more or less separate category:

   - One or more users on a given host communicating with networked PADs
     (i.e. PADs running on a remote host, but which nevertheless need to be
     "addressed" in some fashion by control tools like pavucontrol, pacmd, etc.)


So -- finally -- here are the questions:

NOTE: In what follows "anchored" means "having an associated pid file".

1.  Is there a legitimate user purpose to --use-pid-file=0 ? Or is it intended
    perhaps just for developer use only? (If the latter, there's probably no
    need to document the existence of unanchored PADs in the Wiki blurb).

2.  How do {pavucontrol, pactl} select which PAD to communicate with? I had
    assumed it was via the pidfile, but this seems not to be the case, as it
    is able to establish communication even with a non-anchored PAD:

      # Begin with no PAD running
      $ pulseaudio -v --start --use-pid-file=0
      I: [pulseaudio] main.c: Daemon startup successful.
      $ pavucontrol				# Seems to work normally

    Otoh, pacmd seems to use the pidfile, because if you start pacmd with only
    an unanchored PAD, it whines that a PAD is not running.

3.  Doc for --use-pid-file says: "If this option is disabled it is possible
    to run multiple sound servers per user."

    I played with this as an ordinary user, could not figure out a way to
    get multiple PADs running. E.g.:

      # Begin with no PAD running
      $ pulseaudio -v --start --use-pid-file=0
      I: [pulseaudio] main.c: Daemon startup successful.

      $ pulseaudio -v --start --use-pid-file=0
      E: [pulseaudio] main.c: Daemon startup failed.

    Syslog shows the second attempt failed with EADDRINUSE on bind(). Not sure
    what address is conflicting (the listening port for remote connections?)
    but in any case did not see any options in pulseaudio.1 which allows the
    user to modify any port or other address, in order to avoid conflict.
    So assuming that the magic incantation for running multiple unanchored
    PADs is something entirely different.

    You had remarked earlier:

      "one example would be a scenario where the user has one regular daemon
       running, and then the user runs a PulseAudio test suite that starts
       another daemon for the tests under the same user but in a different
       environment"

    How does that test suite manage to start the second PA daemon? In partick,
    what games does it play with the "different" environment to allow a second
    instance?

That's all for now. :)  Anyway, with answers to the above, I should be able to
get in place a skeleton for the wiki writeup, and then fill in the details on
the fly.

Thanks!

Glenn