Mainloop test uses io callback for PA_IO_EVENT_INPUT on stdin.
With glib enabled PA_IO_EVENT_INPUT translates to glib G_IO_IN event which also
matches descriptor in EOF state. While io callback does not check for EOF after
reading from file descriptor this is causing mainloop-test to repeatedly read 0
bytes once EOF is reached, rearm defer callback and spam test log.
Fix this by disarming io callback when EOF is reached in test run.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/625>
On cpu-volume-test, cpu_info is initialized only on i386/amd64 systems,
and otherwise passed on to pa_cpu_init_orc() uninitialized.
If one was unlucky enough, they could end up with cpu_info.cpu_type ==
PA_CPU_X86 on a non-x86 system, and use and test the Orc codepath
without that being functional, and thus with the test failing.
This has been observed in the wild on the ppc64el Debian buildds. See
Debian bug #982740 for more context.
Define cpu_info here in the same way as in other tests.
Signed-off-by: Faidon Liambotis <paravoid@debian.org>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/511>
When compiled with ASAN: -O1 -fsanitize=address -fno-omit-frame-pointer,
the following issues are seen:
==17217==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fceba414b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fceb9b3eac9 in pa_xmalloc pulse/xmalloc.c:63
#2 0x7fceb9b3ed22 in pa_xmemdup pulse/xmalloc.c:94
#3 0x7fceb9e1eed5 in _pa_xnewdup_internal pulse/xmalloc.h:86
#4 0x7fceb9e1eed5 in init_remap_c pulsecore/remap.c:580
#5 0x7fceb9e1efe5 in pa_init_remap_func pulsecore/remap.c:608
#6 0x5574e72422b7 in remap_init2_test_channels tests/cpu-remap-test.c:303
#7 0x5574e7242420 in rearrange_special_test tests/cpu-remap-test.c:345
#8 0x5574e7245ce5 in srunner_run (/home/eenurkka/pulse/pulseaudio/src/.libs/cpu-remap-test+0x9ce5)
...
SUMMARY: AddressSanitizer: 192 byte(s) leaked in 6 allocation(s).
Fix those issues by freeing the allocated resources properly.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
When compiled with ASAN: -O1 -fsanitize=address -fno-omit-frame-pointer,
the following issue is seen:
==14272==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1072 byte(s) in 1 object(s) allocated from:
#0 0x7f0180966d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f018039f043 in pa_xmalloc0 pulse/xmalloc.c:74
#2 0x7f01803c5cc8 in pa_hashmap_new_full pulsecore/hashmap.c:61
#3 0x7f01803c5df9 in pa_hashmap_new pulsecore/hashmap.c:76
#4 0x556ee75ff7f4 in remove_all_test tests/hashmap-test.c:96
#5 0x556ee7602965 in srunner_run (/home/eenurkka/pulse/pulseaudio/src/.libs/hashmap-test+0x6965)
SUMMARY: AddressSanitizer: 1072 byte(s) leaked in 1 allocation(s).
Fix it by freeing the resource properly.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
I spent a little time working through the implementation of
pa_hashmap, and wrote a test suite while doing so. It tests a few
basic edge cases, like saturating all buckets of the hashtable.
remixing-produce-lfe controls upmixing, and remixing-consume-lfe
controls downmixing. The motivation is that a user might want to
synthesize LFE while playing stereo audio on his/her 5.1 speakers,
but at the same time follow the industry recommendation to omit
the LFE channel when producting a stereo downmix (e.g. for headphones)
from 5.1 content. Or the other way round.
Fixes: #753.
It is possible that we might want to have a separate userdata to be used
for these callbacks, so let's split them out.
This is particularly needed when using an pa_rtpoll_item around pa_fdsem
since that uses its own before/after callback but will essentially have
whatever is using the fdsem set up the work callback appropriately (and
thus at least the work callback's userdata needs to be separated from
the before/after callback -- we might as well then just separate all
three).
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
Silences these warnings:
[509/574] Compiling C object 'src/tests/a4ccf2d@@alsa-mixer-path-test@exe/alsa-mixer-path-test.c.o'.
../src/tests/alsa-mixer-path-test.c:24:20: warning: ‘load_makefile’ defined but not used [-Wunused-function]
static pa_strlist *load_makefile() {
^~~~~~~~~~~~~
../src/tests/alsa-mixer-path-test.c:17:20: warning: ‘get_default_paths_dir’ defined but not used [-Wunused-function]
static const char *get_default_paths_dir(void) {
^~~~~~~~~~~~~~~~~~~~~
The original atomic implementation in pulseaudio based on
libatomic stated that the intent was to use full memory barriers.
According to [1], the load and store implementation based on
gcc builtins matches sequential consistent (i.e. full memory barrier)
load and store ordering only for x86.
I observed random crashes in client applications using memfd srbchannel
transport on an armv8-aarch64 platform (cortex-a57).
In all those crashes the first read on the pstream descriptor
(the size field) was wrong and looked like it contained old data.
I boiled the relevant parts of the srbchannel implementation down to
a simple test case and could observe random test failures.
So I figured that the atomic implementation was broken for armv8
with respect to cross-cpu memory access ordering consistency.
In order to come up with a minimal fix, I used the newer
__atomic_load_n/__atomic_store_n builtins from gcc.
With
aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425
they compile to
ldar and stlxr on arm64, which is correct according to [1] and [2].
The other atomic operations based on __sync builtins don't need
to be touched since they already are of the full memory barrier
variety.
[1] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
[2] <https://community.arm.com/developer/ip-products/processors
/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions>
This test relies on parsing the generated Makefile. A meson equivalent
requires to re-write all the parser.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
There's already a hook that modifies the search path when run from the
build tree.
if (pa_run_from_build_tree()) {
pa_log_notice("Detected that we are run from the build tree, fixing search path.");
#ifdef MESON_BUILD
c->dl_search_path = pa_xstrdup(PA_BUILDDIR PA_PATH_SEP "src" PA_PATH_SEP "modules");
#else
c->dl_search_path = pa_xstrdup(PA_BUILDDIR);
#endif
} else
I'm not sure how it works behind the hood, but by setting
--dl-search-path, we get errors in the logs when running `make
check-daemon`:
E: [pulseaudio][daemon/ltdl-bind-now.c:75 bind_now_open()] Failed to open module /home/arno/proj/pulse/src/pa.up/src/.libs/.libs/module-native-protocol-unix.so:
/home/arno/proj/pulse/src/pa.up/src/.libs/.libs/module-native-protocol-unix.so: cannot open shared object file: No such file or directory
I: [pulseaudio][pulsecore/module.c:197 pa_module_load()] Loaded "module-native-protocol-unix" (index: #3; argument: "").
So basically, PA tries two paths, fails the first time (obviously we can
see the path is not correct), then tries again with another path (where
does it gets it?) and succeeds. So there's no obvious error if you don't
look at the log.
This commit removes the useless `--dl-search-path`, which has the effect
to remove the errors in the logs.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This adds API to allow clients to schedule a callback in the mainloop
thread without the mainloop lock being held. This is meant for a case
where the client might be dealing with locking its own objects in
addition to the mainloop thread itself. In this case, it might need ton
control the locking order of the two, to match the order in other
threads, as it might not always be able to allow for its objects to be
locked after the mainloop thread lock.
So far PulseAudio only supported two different work formats: S16NE if
it's sufficient to represent the input and output formats without loss
of precision and FLOAT32NE in all other cases. For systems that use
S32NE exclusively, this results in unnecessary conversions from S32NE to
FLOAT32NE and back again.
Add S32NE remap operations and make use of them (for the COPY and
TRIVIAL resamplers) if both input and output format are S32NE. This
avoids the back and forth conversions between S32NE and FLOAT32NE,
significantly improving performance for those cases.
pa_init_remap_func() takes care to initialise pa_remap_t.do_remap to
NULL before calling init_remap_func (the CPU-specific remap init
function) and invokes init_remap_c if init_remap_func did not set
pa_remap_t.do_remap to non-NULL. remap_init_test_channels() calls
init_remap_func() directly so it must make sure pa_remap_t.do_remap is
set to NULL. Otherwise we'll end up with a random value in
pa_remap_t.do_remap if there is no CPU-optimised remap function for the
current operation.
We split out some of the check-daemon tests that take a long time to
run, and also reduce how long we wait for the daemon to start up. This
should make the CI process quicker.
This adds some basic infrastructure to test passthrough support. Right
now, it just creates a passthrough stream and makes sure negotiation
works. We'll add in more tests as we go along.
This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
