The code was mixing sink and sink input domain rate updates, and that
only works if the rate of the RTP stream is the same as the rate of the
sink. This changes all the calcuations to be on the sink-input rate,
since that's the rate we are trying to guess (and resample for).
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>
This patch deals with the case that applications start new streams corked.
In case of module-role-cork it will only mute the stream because corking is
removed later by the application.
When a trigger stream changes mute or cork state, the cork streams should
react to this. The same applies if a stream changes its role to or from the
trigger role.
When corking do not ignore streams without media.role. Instead treat
them as if media.role="no_role", so that you can specify "no_role" as
trigger or cork role.
If u->save_time_event is non-NULL when the module is being unloaded,
it means that there are some changes to the database that haven't
yet been flushed to the disk.
Acked-by: David Henningsson <david.henningsson@canonical.com>
By refactoring volume probing into its own function, we can reduce
indentation a lot. Also, if an error occurs during the volume probe,
that volume element is now always skipped (instead of taking down
the entire path with it).
Also, a bug for elements with more than two channels is fixed, as
previously, the volume parsing code was continuing, potentially
referencing somewhere outside the array (which has max two channels).
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
If you have headphones plugged in and plug in HDMI; you want sound
to stay on headphones.
If you have HDMI plugged in and you plug in headphones; you want sound
to switch to headphones.
Hence we need to take priority into account as well when determining
whether to switch to a new profile or not.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93903
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
It is expected that the underlying AGC mechanism will likely provide a
single volume for the source rather than a per-channel volume. Dealing
with per-channel volumes just adds complexity with regards to the
actual volume setting (depending on whether volume sharing is enabled or
not, we would set the volume on the source output of the virtual source,
and their sample specs may be different).
Using a single volume allows us to sidestep this problem entirely.
This is required to have unequal channel counts on capture in and out
streams, which is needed for beamforming to work. The deinterleaved API
only works with floating point samples.
The calculations around how many samples were sent to the canceller
engine was not updated when we started supporting different channel
counts for playback and capture.
This is needed for building with anonymous unions. A bunch of calls to
fail() that used to mysteriously work need fixing -- fail() is a macro
that takes a printf-style message as an argument. Not passing this
somehow worked with the previous compiler flags, but breaks with
-std=c11.
The AGC code no longer seems to honour the analog volume limits we set,
and internally uses 0-255 as the volume range. So we switch to use that
(keeping the old API usage as is in case this gets fixed upstream).
This allows us to inherit the sample spec parameters from the sink and
source master (rather than forcing 32 kHz / mono). It is still possible
to override some of the parameters for the source side with modargs.
My original testing showed that these parameters provided a decent
perf/quality trade-off on lower end hardware (which I no longer have
access to). I figure it makes sense to continue with that for now, and
in the future this can be relaxed (use_master_format=yes could be the
default, and resource-constrained systems can disable it).
