Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-09-02 13:24:00 +0300]:
> On Sun, 2014-08-31 at 19:45 -0600, Glenn Golden wrote:
> > 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.]
>
> This is extremely rare, but I think this is "officially supported" via
> setting XDG_RUNTIME_DIR and using a different startup script that
> doesn't conflict with the primary daemon (two daemons can't use the same
> hardware simultaneously). My personal view is that --use-pid-file is
> nowadays unnecessary (I don't know if it ever was necessary), and not
> recommended for any use case. If the user uses it and something breaks,
> (s)he will get to keep both pieces.
>
> > - Multiple users on a given host, each of whom may be running one or more
> > PADs on that host. [Think so, not sure.]
>
> A host can have multiple seats, and each seat can have multiple sessions
> from different users. Only one session can be active at a time on any
> given seat, however. Inactive sessions will not have access to audio
> hardware. As long as you don't try to break the
> "one-active-session-per-seat" rule, things should work fine out of the
> box. If each seat has separate sound cards (this usually requires manual
> udev configuration), then everything should work great.
>
> Sharing a sound card between multiple simultaneous active sessions isn't
> currently supported, although with sufficient manual configuration there
> are ways to make it work.
>
> > - Single system-wide PAD on a given host. [Certain]
> >
> > - Multiple system-wide PADs on a given host. [No clue.]
>
> Not supported. It may be possible to make this work somehow, but if it's
> not possible, that's not a bug.
>
> > - One or more system-wide PADs operating concurrently with one or more
> > user PADs. [No clue]
>
> Not currently supported, but I'm currently working on making this a
> supported setup (one system-wide daemon for shared sound cards plus the
> usual per-user daemons for per-seat sound cards).
>
> > 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).
>
> I don't know what motivated the addition of the --use-pid-file option.
> As I said above, I'm not aware of any use cases that would require that
> option.
>
> > 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
>
> The client library (libpulse) tries to connect to $runtimedir/native,
> i.e. the native protocol socket. The pid file is not involved.
>
> > 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.
>
> pacmd uses a different protocol, but the same approach as libpulse:
> instead of $runtimedir/native, the socket location is $runtimedir/cli.
> The reason why pacmd didn't work was that module-cli-protocol-unix isn't
> loaded by default, so the socket didn't exist. Then why does pacmd work
> if you don't use --use-pid-file=0? Well, there's this crazy hack: if the
> socket can't be found, pacmd sends SIGUSR2 to the daemon, which will
> then cause module-cli-protocol-unix to be loaded. The pid file is needed
> for figuring out where to send the signal.
>
> pacmd is redundant and weird, I'd like to drop it. Unfortunately, many
> people are using it in scripts and stuff.
>
> > 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.
>
> The bind() error might have happened when protocol-native-protocol-unix
> tried to create the listening socket. You could set XDG_RUNTIME_DIR to
> use a different location for the socket, or you could pass -n and --file
> to pulseaudio to use a different startup script (the default script
> is /etc/pulse/default.pa). In the startup script you can then specify
> which socket module-native-protocol-unix should use.
>
> > 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?
>
> >From src/tests/test-daemon.sh (uninteresting stuff removed and comments
> added):
>
> unset DBUS_SESSION_BUS_ADDRESS
> unset DBUS_SESSION_BUS_PID
>
> # This will start a new D-Bus bus and set DBUS_SESSION_BUS_ADDRESS
> # and DBUS_SESSION_BUS_PID so that they point to the newly created
> # bus.
> eval `dbus-launch --sh-syntax`
>
> # I suppose we could also set XDG_RUNTIME_DIR, and maybe it would
> # even be better that way, but setting PULSE_RUNTIME_PATH
> # achieves pretty much the same thing.
> TEMP_PULSE_DIR=`mktemp -d`
> export PULSE_RUNTIME_PATH=${TEMP_PULSE_DIR}
>
> # Note the use of -n to prevent default.pa from being loaded,
> # and the list of modules that doesn't include any modules that
> # would touch the hardware, as that would conflict with the
> # user's primary daemon.
> pulseaudio -n \
> --log-target=file:${PWD}/pulse-daemon.log \
> --log-level=debug \
> --load="module-null-sink" \
> --load="module-null-source" \
> --load="module-suspend-on-idle" \
> --load="module-native-protocol-unix" \
> --load="module-cli-protocol-unix" \
> --dl-search-path="$(dirname $SCRIPTNAME)/.libs/" \
> &
>
Whew. OK, thanks for your time on that detailed response.
This weekend is devoted to rolling up my sleeves and trying to produce
something useful for the wiki blurb, given all of your and David's input and
feedback so far.
To be honest though, I'm not all that confident about coming up with something
much better than a water-color impression, but I'll take a shot at it. There
are so many moving parts affecting the "which server" question that it's
difficult to succinctly summarize _any_ aspect of it without footnoting it to
death to cover all the corner cases.
Anyway, we'll see.
A few loose-end questions if you have time:
* Can you point me to any doc that describes the semantics of
PULSE_RUNTIME_PATH? It's not mentioned in pulse-daemon.conf.5 or in
pulseaudio.1. (It doesn't even show up on the first page of results
from Google. How's that for 'obscure'? :) )
* Do you have a pointer to any doc which describes how PA distinguishes
between the concepts of "user", "seat", and "session"?
Thanks,
Glenn
