With Tanu's patch, the server no longer starts when a server is configured.
While this is sensible in most circumstances there is a corner case where
we still want to start.
In a typical X11 login, module-x11-publish will be loaded and will thus
set the PULSE_SERVER X11 property on the root window. This then hits the
check introduced in f1d1447e and exits. If PA had previously crashed
(thus leaving behind it's X11 properties) then this means that we will not
autospawn nor even allow ourselves to be started manually until
pax11publish -r is run to clear out the X11 properties. This is obviously
not desirable.
This patch introduces a more in-depth check of the server. If it looks like
a local unix domain socket, then we do not exit straight away and instead
probe further. This should not pose any problems with e.g. remote SSH
usage as the DBus Machine ID is used in the server string.
As spotted by Tanu Kaskinen:
The first process: daemon_pipe is not closed if the first fork() call
fails. Even if it doesn't fail, the first process never closes
daemon_pipe[0].
The second process: daemon_pipe[1] is not closed if anything fails
between the first and the second fork() call. Also, if the second fork
fails, then the finish section writes to daemon_pipe2[1], even though
only the third process should do that. Also, if anything fails between
the first and the second fork, then the second process never writes
anything to daemon_pipe[1]. I don't know what happens in the first
process in this case - does it get an error or does pa_loop_read() get
stuck.
The third process: No problems :)
The previous commit intoduced a double fork which caused a more or less immediate
successful return prior to the hard work of actually starting a daemon.
This patch simply used pipe() to only signal our father when the daemon really
has finished starting.
This patch enables logging of text debug messages (pa_log feature) into a file or a device driver.
Example : pulseaudio --log-target=file:./mylog.txt
(Minor tweaks by Colin + Arun)
This adds volume scaling for 1- and 2-channel software volume scaling
using Orc. While testing the MMX and SSE backends on a Core2, I see an
~2x performance benefit over the hand-rolled MMX and SSE code. Since I
haven't been able to test on other architectures, the Orc code is only
used when MMX/SSE* is present. This can be changed in the future after
testing on AMD and ARM machines.
The check whether POSIX socket.h or WIN32 winsock2.h must be included can be
made centrally. The downside is that some functionality of e.g. arpa/inet.h is
also implemented in winsock.h, so that some files that don't use socket
functions, but do use inet.h functions, must also include pulsecore/socket.h.
(as well as arpa/inet.h)
Instead <pulsecore/poll.h> should be included. That file includes poll.h on
platform where it is appropriate. Also remove some unnecessary <ioctl.h>
includes.
Therefore, we must reflect this in the default.pa. Several users
have reported an error with consolekit when starting a self-built PA
due to the default config not working properly. This works around the
issue but we should include a warning on configure about the lack of
DBUS and udev support as this is a common mistake.
This is needed to better support out of tree builds (including
distcheck) and to ensure the necessary folders are created in the
build tree on configure and also works around an intl-tools bug
(https://bugs.launchpad.net/intltool/+bug/605826)
The Makefile.am's used are minimal (and in some cases completely
blank). At present they do not include anything interesting
with the majority of the real work still done by the monolitic
src/Makefile.am
It may make sense to start splitting out src/Makefile.am into
smaller chunks but this commit makes the minimum changes to address
the issues that result from using make distcheck and other out of
tree builds.
Note: This 'breaks' the ability to type make in e.g. the src/modules
folder and have all of PA rebuilt accordingly (this is because the
static Makefiles previously present just did a "make -C ..") which
was purportedly for use in emacs. But I'm sure there will be a better
and more robust way to configure emacs to do your builds properly if
this behaviour is still desirable.
This retains CPU information (processor type and supported features) in
pa_core, so that this information can be used by modules at init time to
figure out what optimisations may be used.
Lennart,
Apparently I was debugging this at the same time as you. I can't figure out
why my Fedora 11 install with glibc-2.10 has a glibc realpath that doesn't
match the gnu documentation and returns null. But it does.
Your commit aa8ce5bb9b almost fixed my
problem, but it needs a tweak.
Thanks,
David Yoder
There are multiple package management systems out there which implement
packages using symlinks. The recent (otherwise useful) check to ensure that
a re-executed pulseaudio is actually reexecuting itself unfortunately breaks
in the presence of all these packaging systems, because PA_BINARY refers
to its installed location (e.g. /usr/local/bin/pulseaudio), which is a
symlink to the binary (e.g. /usr/local/stow/pulseaudio-0.9.18/bin/pulseaudio),
because /proc/self/exe always contains the canonical path of the executable,
with all symlinks resolved.
(At least one distribution uses a symlink-based packaging system, so
will be forced to apply this locally in any case.)
The fix is simple: canonicalize PA_BINARY before equality-testing. (This
should be completely safe, because the OS does just that when PA_BINARY
is executed.)
The patch is against 0.9.18, but applies without fuzz to current master.
