If pa_memblockq_push needs to write into the middle of a chunk, target chunk
is split into head and tail sharing the same memblock. Size of head and
tail chunks is adjusted correctly, head chunk pointer into memblock remains
unchanged from target chunk.
The problem is with tail chunk offset into memblock which should be advanced
past write region of memblock, but currently it is left as 0.
This is causing an issue where seeking a few frames back into the middle of
memblock and writing a frame there ends up with tail chunk referencing frames
from very beginning of memblock causing corrupted output from memblockq.
Fix this by adjusting tail chunk offset into memblock past write region and
add a test case.
Fixes#3789
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/798>
GCC warns on all these `fail_unless` calls:
warning: too many arguments for format [-Wformat-extra-args]
`fail_unless` only takes an expression and optionally a string literal
as message with formatting args. Passing NULL for this message should
not be necessary as indicated by all the other tests not passing it
either.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/653>
This patch adds a test program that generates a square wave of a given frequency,
length and sample rate. This is then resampled to another rate, rewound and the
rewound part is run through the resampler again. After that, the results of the
first and second resampler pass are compared.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/120>
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>
