Coming down the home stretch pestering you guys with pa_context_connect()
questions. Hopefully this is the last set, please bear with me.
Begin with:
* XDG_RUNTIME_DIR unset
* PULSE_AUDIO envar unset
* PULSE_AUDIO X11 property unset
* default-server in ~/.config/pulse/client.conf is null
* autospawn = no (in ~/.config/pulse/client.conf)
* No PA server is running
* ~/.config/pulse contains only client.conf, no other files or dirs
* There are no extant directories named /tmp/pulse*
Now with an instrumented version of pactl (which dumps server_list), and as a
non-root user, run
$ PULSE_LOG=5 pactl info
and see that it constructs server_list with "/tmp/pulse-XXXX/native" as the
first (user PAS) entry, where XXXX is a 12-charater hash. (The second entry
is for the [non-existant] system instance; let's ignore that, it's not relevant
to what follows.)
Pactl then tries to connect to the user PAS via the above socket path. This of
course fails, since there's no server running, and pactl complains and exits
as expected.
Afterwards, the observed file situation is:
* ~/.config/pulse contains a newly-created symlink
HOST-runtime -> /tmp/pulse-XXXX
where HOST is the hostname on which pactl was executed.
* /tmp now contains a newly created empty directory /tmp/pulse-XXXX.
Several questions arise:
1. Why is it _creating_ a new runtime dir /tmp/pulse-XXXX (and associated
symlink in ~/.config/pulse) when it seems like what it ought to be doing
in this situation is simply looking for an extant runtime dir (given that
autospawn is disabled)?
2. Why does it name the symlink in ~/.config/pulse as HOST-runtime, rather
than MID-runtime (since on my system /etc/machine-id is available)?
3. What information participates in the hashing that generates the XXXX?
(The reason for this question is that it seems to generate identical XXXX
every time, if one starts with the initial conditions described above.)
4. In the constructed server_list, it seems curious that it contains the
dereferenced symlink (i.e. the target directory /tmp/pulse-XXXX/native)
rather than the symlink itself (~/.config/pulse/HOST-runtime). (This is
a minor point; just asking because seems to me that the symlink is the
more useful piece of info to be reported when debug logging is enabled,
since in effect, that's the runtime dir of interest.)
