I will modify module-switch-on-port-available so that it will keep
track of which input and output port the user prefers on the card,
based on the user's profile and port switches. The preference needs
to be saved on disk, for which I will use module-card-restore.
To facilitate communication between the two modules, this patch adds
preferred_input_port and preferred_output_port fields to pa_card, and
a hook for monitoring the variable changes. It would be nice if the
two modules would communicate directly with each other, but
implementing that would be somewhat complicated, so I chose this time
for adding the functionality to the core. In theory some other routing
module might want to manage the new variables instead of
module-switch-on-port-available, but admittedly that's not very likely
to happen...
Now that all layers in the stack support memfd blocks, add memfd
support for the daemon's global core mempool. Also introduce
"enable-memfd=" daemon argument and configuration option.
For now, memfd support is an opt-in feature to be activated only
when daemon's enable-memfd= is set to yes.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Now that all layers in the stack support memfd blocks, add memfd
pools support for client context and audio playback data.
Use such memfd pools by default only if the server signals memfd
support in its connection negotiations.
Also add ability for clients to force-disable memfd transport
through the `enable-memfd=' client configuration option.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
pa_sink_input_update_proplist() is inconvenient in many cases, because
it requires allocating a new proplist, even if the goal is to just set
one property. pa_sink_input_update_properties also can't properly log
property changes, because it has to assume that all values are
arbitrary binary data.
This patch adds pa_sink_input_set_property() for setting a string
value for a single property, and pa_sink_input_set_property_arbitrary()
for setting a binary value for a single property.
pa_sink_input_update_properties() is reimplemented as a wrapper around
pa_sink_input_set_property_arbitrary() to centralize logging and
sending change notifications.
(The above mentions only sink input functions for brevity, but the
same changes are implemented for source outputs too.)
Before a device is unlinked, the unlink hook is fired, and it's
possible that a routing module tries to move streams to the unlinked
device in that hook, because it doesn't know that the device is being
unlinked. Of course, the unlinking is obvious when the code is in an
unlink hook callback, but it's possible that some other module does
something in the unlink hook that in turn triggers some other hook,
and it's this second hook where the routing module may get confused.
This patch adds an "unlink_requested" flag that is set before the
unlink hook is fired, and moving streams to a device with that flag
set is prevented.
This patch is motivated by seeing module-device-manager moving a
stream to a sink that was being unlinked. It was a complex case where
an alsa card was changing its profile, while an echo-cancel sink was
connected to the old alsa sink. module-always-sink loaded a null sink
in the middle of the profile change, and after a stream had been
rescued to the null sink, module-device-manager decided to move it
back to the old alsa sink that was being unlinked. That move made no
sense, so I came up with this patch.
srbchannel needs fd passing. Otherwise we get the following error
for systems without SCM_CREDENTIALS support:
Code should not be reached at pulsecore/pstream-util.c:95,
function pa_pstream_send_tagstruct_with_fds(). Aborting.
[[ The root cause is that we define HAVE_CREDS only if
SCM_CREDENTIALS is defined, but SCM_CREDENTIALS is a Linux-specific
symbol. Thus HAVE_CREDS is always disabled on Solaris.
And since pulse couples the non-portable creds passing support
with the portable fd passing one, through _35_ places where
HAVE_CREDS is used, a real fix needs a PA redesign -- assuming that
latency on Solaris is something people care about. ]]
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94339
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Now that we have the necessary infrastructure to memexport and
mempimport a memfd memblock, extend that support higher up in the
chain with pstreams.
A PA endpoint can now _transparently_ send a memfd memblock to the
other end by simply calling pa_pstream_send_memblock() – provided
the block's memfd pool was earlier registered with the pstream.
If the pipe does not support memfd transfers, we fall back to
sending the block's full data instead of just its reference.
** Further details:
A single pstream connection usually transfers blocks from multiple
pools including the server's srbchannel mempool, the client's
audio data mempool, and the server's global core mempool.
If these mempools are memfd-backed, we now require registering
them with the pstream before sending any blocks they cover. This
is done to minimize fd passing overhead and avoid fd leaks.
Moreover, to support all these pools without hard-coding their
number or nature in the Pulse communication protocol itself, a new
REGISTER_MEMFD_SHMID command is introduced. That command can be
sent _anytime_ during the pstream's lifetime and is used for
creating on demand SHM ID to memfd mappings.
Suggested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Color global mempools with a special mark. This special marking
is needed for handling memfd-backed pools.
To avoid fd leaks, memfd pools are registered with the connection
pstream to create an ID<->memfd mapping on both PA endpoints.
Such memory regions are then always referenced by their IDs and
never by their fds, and so their fds can be safely closed later.
Unfortunately this scheme cannot work with global pools since the
registration ID<->memfd mechanism needs to happen for each newly
connected client, and thus the need for a more special handling.
That is, for the pool's fd to be always open :-(
Almost all mempools are now created on a per-client basis. The
only exception is the pa_core's mempool which is still shared
between all clients of the system.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
To transfer memfd-backed blocks without passing their fd every time,
thus minimizing overhead and avoiding fd leaks, a command is sent
with the memfd fd as ancil data very early on.
This command has an ID that uniquely identifies the memfd region.
Further memfd block references are then exclusively done using this
ID.
This commit implements the details of such 'permanent' mappings on
the receiving end, using memimport segments.
Suggested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Memfd is a simple memory sharing mechanism, added by the systemd/kdbus
developers, to share pages between processes in an anonymous, no global
registry needed, no mount-point required, relatively secure, manner.
This patch introduces the necessary building blocks for using memfd
shared memory transfers in PulseAudio.
Memfd support shall also help us in laying out the necessary (but not
yet sufficient) groundwork for application sandboxing, protecting PA
from its clients, and protecting clients data from each other.
We plan to exclusively use memfds, instead of POSIX SHM, on the way
forward.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
pa_shm_create_rw() is responsible for creating two types of memory:
POSIX shared memory and regular malloc()-ed ones.
A third memory type, memfds, will be added later. Thus to add this
extra shared memory type in a sane manner, refactor private memory
allocations into their own static methods.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Soon we're going to have three types of memory pools: POSIX shm_open()
pools, memfd memfd_create() ones, and privately malloc()-ed pools.
Thus introduce annotations for the memory types supported and change
pa_mempool_new() into a factory method based on required memory.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
The PA daemon currently uses a single SHM file for all clients
sending and receiving commands over the low-latency srbchannel
mechanism.
To avoid leaks between clients in that case, and to provide the
necessary ground work later for sandboxing and memfds, create the
srbchannel SHM files on a per-client basis.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
In future commits, server-wide SHMs will be replaced with per-client
ones that will be dynamically created and freed according to clients
connections open and close.
Meanwhile, current PA design does not guarantee that the per-client
mempool blocks are referenced only by client-specific objects.
Thus reference count the pools and let each memblock inside the pool
itself, or just attached to it, increment the pool's refcount upon
allocation. This way, per-client mempools will only be freed when no
further component in the system holds any references to its blocks.
DiscussionLink: https://goo.gl/qesVMV
Suggested-by: Tanu Kaskinen <tanuk@iki.fi>
Suggested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
The daemon `shm-size-bytes' configuration value was read, and then
directly used, for creating the initial server-wide SHM files.
This is fine for now, but soon, such server-wide SHMs will be replaced
with per-client SHM files that will be dynamically created and deleted
according to clients open and close. Thus, appropriately cache this
configuration value.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
sd_journal_send() implicitly add fields for the source file,
function name and code line from where it's invoked. As code
location fields CODE_FILE, CODE_LINE and CODE_FUNC are handled
by PA's log module, we do not want the automatic values
supplied by the sd_journal API.
Without suppressing these, both the actual log event source
and the call to sd_journal_send() will be logged:
$ journalctl -b -f -o json-pretty
[...]
CODE_FILE : [ pulsecore/log.c, pulsecore/module.c ],
CODE_LINE : [ 505, 181 ],
MESSAGE : Failed to load module module-gconf
CODE_FUNC : [ pa_log_levelv_meta, pa_module_load ],
[...]
(Commit log adapted from abrt libreport commit d1eaae97f0287f)
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
In file included from pulse/timeval.c:32:0:
pulse/timeval.c: In function 'pa_timeval_add':
./pulsecore/macro.h:303:28: warning: left shift of negative value [-Wshift-negative-value]
? ~(~(type) 0 << (8*sizeof(type)-1))
reported by Ubuntu gcc-6
gcc-6 adds -Wshift-negative-value (enabled by -Wextra) which warns
about left shifting a negative value. Such shifts are undefined
because they depend on the representation of negative values.
also works with -Wshift-overflow=2
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
This gets rid of an error message from the debug log. If
volume_factor_source would actually be used somewhere, this bug would
have caused more severe problems.
volume_factor_source should have the source's channel map. When moving
the stream, the volume needs to be remapped from the old source's
channel map to the new source's map. However, when the stream is being
moved, there is a period where the old source has already been
forgotten and the new source isn't yet known, so the remapping can't
be done directly between the two channel maps. Instead, the volume is
remapped from the old source's map to the stream's own map when the
move starts, and again remapped from the stream's map to the new
source's map when the move finishes.
The first remapping was missing, causing the second remapping fail and
print an error to the log.
(I checked the sink input code as well. It didn't have this bug.)
Applying the volume after resampling means mismatch between the volume
channel map and the data channel map.
volume_factor_source is not currently used anywhere, so this bug
hasn't been causing any problems. I noticed it while reading the code.
There is no way to check CPU type in a portable way across ABIs.
Assume if pointers are 64-bit that CPU is capable to perform fast
64-bit operations. Add an extra check to handle x32-ABI.
PulseAudio by default builds with -Wundef. If we add -Werror=undef this
missing define is fatal. By default build log is full of entries like:
In file included from ./pulsecore/core.h:47:0,
from ./pulsecore/module.h:31,
from ./pulsecore/sink-input.h:31,
from pulsecore/sound-file-stream.c:36:
./pulsecore/sample-util.h: In function 'pa_mult_s16_volume':
./pulsecore/sample-util.h:58:5: warning: "__WORDSIZE" is not defined [-Wundef]
#if __WORDSIZE == 64 || ((ULONG_MAX) > (UINT_MAX))
^
(NetBSD-7.99.21 with default GCC 4.8.5)
This change fixes build issues on NetBSD.
This also address a bug reported by Shawn Walker from Oracle (possibly Solaris):
Bug 90880 - builds can fail due to non-portable glibc-specific internal macro usage
This allows a configuration scheme where after loading configuration
from "somefile", the parser loads configuration from files in
directory "somefile.d". This feature needs to be enabled on a per-file
basis, though, and this patch doesn't yet enable the feature for any
files.
The relationship between sinks, sources, cards, profiles, and ports
is becoming ever more intertwined, to the point that if you try to
include one file from the other, you're likely to end up with some
weird error somewhere else.
Work around this by creating a new typedefs.h, which does not depend
on anything else, and just creates a few typedefs.
(Can be expanded with more typedefs in the future if the need arises.)
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
From the NetBSD manual:
The first argument of these functions is of type int, but only a very
restricted subset of values are actually valid. The argument must either
be the value of the macro EOF (which has a negative value), or must be a
non-negative value within the range representable as unsigned char.
Passing invalid values leads to undefined behavior.
-- ctype(3)
pa_module_unload() takes two pointers: pa_module and pa_core.
The pa_core pointer is also available via the pa_module object,
so the pa_core argument is redundant
[David Henningsson: Rebased to git HEAD]
In case pa_card_set_profile is called with save=false, then probably
it makes more sense not to update the port's preferred profile as well.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
It can be useful for routing modules to know a profile's input
and output parts, in order to e g change output profile
while keeping the input profile unchanged.
For now filling in these fields is optional and a routing module
must be able to handle NULL in these fields.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Without this, we hit an assert because the channel count in
new_reference (which was inherited from the master) is lower than the
channel count of the filter.
packet.h defines:
typedef struct pa_packet pa_packet;
and packet.c defines:
typedef struct pa_packet {
...
} pa_packet;
With old versions of gcc (such as gcc 4.5) this causes a redefinition
error at compile time:
pulsecore/packet.c:43:3: error: redefinition of typedef 'pa_packet'
pulsecore/packet.h:26:26: note: previous declaration of 'pa_packet' was here
In order to fix this, this commit changes the definition in packet.c
to just:
struct pa_packet {
...
};
This way, the contents of the structure remain opaque to users of
pa_packet outside packet.c, and the 'pa_packet' type remains usable.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91334
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The drain reporting improvements that were added to alsa-sink were only
being applied to directly connected sink inputs. This patch makes the
same logic also recurse down the filter hierarchy, so drains are
acknowledged more accurately (and not late) even if there is a filter
sink in between.
Also does some minor reorganisation of the code and sprinkles in some
comments as documentation.
The 0.1.2 version of libsoxr fixes soxr_process() crash after soxr_clear() is used, so check the library version at compile time and use soxr_clear() if possible.
The gnome/unity-control-center UIs have a master volume slider, and
three sub-sliders: balance, fade, and subwoofer. Balance and fade
use PA's set_balance and set_fade APIs accordingly, but the subwoofer
slider sometimes does unintuitive things.
In order to make that slider behave better, let's add a LFE balance
API that these volume control UIs can use instead. With this API,
the UI can balance between "no subwoofer" and "only subwoofer" with
"equal balance" in the middle, which would make it more consistent
with the behaviour of the other sliders.
BugLink: https://bugzilla.gnome.org/show_bug.cgi?id=753847
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
We need to guard the pstream with an extra ref to ensure
it is not destroyed at the time we check whether or not the
srbchannel is destroyed.
Reported-by: Takashi Iwai <tiwai@suse.de>
BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=950487
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
With the exception of when trying to clean up shm files,
it's useful to warn if opening them fails, regardless of reason.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
