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/" \
&
--
Tanu
