We have a requirement to "hide" some hardware drivers, because
other (main) UCM configuration will refer them.
This patch use special error codes to notify the upper layers
to skip the module loading.
BugLink: https://github.com/alsa-project/alsa-ucm-conf/issues/30
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
pa_core_check_idle() uses pa_core.exit_idle_time, which is set after the
pa_core_new() call, so pa_core_check_idle() needs to be called later.
This patch preserves the fact that core state is set to PA_CORE_RUNNING
after checking idle (now in main). It doesn't seem to matter anyway and
main(pa_core_new(state:PA_CORE_STARTUP)->...->state:PA_CORE_RUNNING)
seems right as well.
There were three bugs:
1) j->state_plugged was set to PA_AVAILABLE_UNKNOWN too early. It must
be set only after we have found that the jack is shared by two ports.
The result of setting it too early was that no jack ever could have
the PA_AVAILABLE_YES status.
2) The inner jack loop iterated through p->jacks instead of p2->jacks,
so the code didn't compare jacks between two ports at all. As a result
all ports were put in the same availability group.
3) The inner jack loop checked j->state_plugged instead of
j2->state_plugged. The result was that the speaker port, which uses the
Headphone jack to toggle between unknown and unavailable, was put in the
same group with the headphone port.
This change prepares for adding a doxygen target to the Meson build
system. The DOXYGEN_OUTPUT_DIRECTORY substitution variable is needed so
that the output will go to the build directory. I also replaced @srcdir@
with @top_srcdir@. I think it looks cleaner, since the ".." parent
directory traversal is avoided. It also happened to make writing the
Meson rules easier.
In the current scenario of reading samples from the appsink, it is
observed that we do not actually read all the data available in the
appsink to read. This results in a choppy sound or heard as gaps in
the playback.
The underlying reason for this happening is as follows. Let's say
the appsink new sample callback is called 2-3 times, but, with the
underlying fdsem post machinery when pa_rtp_recv eventually gets
called, there would be those 2-3 samples to read. However, we were
only reading one sample in the current implementation.
Fix this by reading all samples from the appsink in a loop, coalescing
them and then writing to the memchunk.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/889
Signed-off-by: Sanchayan Maity <sanchayan@asymptotic.io>
If the profile is generated from UCM, the priority won't be set so it
stays as 0.
Assume a card has two available profiles, when the selected one becomes
unavailable, module-switch-on-port-available's find_best_profile()
should pick the next available one. However, since the priority is 0,
the "off" profile was chosen instead of the available one.
So let's set the priority to 1 to make profile that is available has
higher priority than "off" profile.
Pipewire has started shipping copies of PulseAudio's ALSA card profiles.
It would be useful if both projects could share the same profiles and
this patch is a step toward that.
UAC v2 and v3 support insertion control (jack detection), and the
created jack mixers have "- Input" suffix and "- Output" suffix for
input jack and output jack, respectively.
Add these jacks so we don't always need to rely on UCM or PulseAudio
profile-set.
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>
When the Thumb instructions set is used and frame pointers are enabled
(-fno-omit-frame-pointer), r7 can't be used, because it's used for the
frame pointer. Trying to use r7 caused the compilation to fail.
Thanks to Andre McCurdy for suggesting[1] this fix, all I had to do was to
test that it works. The code builds now, and cpu-remap-test also
succeeds.
[1] https://lists.openembedded.org/g/openembedded-core/message/136786
When playing music for a period of time, the Shared Memory is
frequently accessed, and occasionally read/write errors occur,
which causes the program to crash
[Current thread is 1 (Thread 0xffff86823010 (LWP 2841))]
(gdb) bt
0 0x0000ffff8702a714 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
1 0x0000ffff870188e8 in __GI_abort () at abort.c:79
2 0x0000ffff873b5728 in do_read (p=p@entry=0x3673a170, re=re@entry=0x3673a338) at pulsecore/pstream.c:856
3 0x0000ffff873b7fd8 in do_pstream_read_write (p=0x3673a170) at pulsecore/pstream.c:248
4 0x0000ffff873b8368 in srb_callback (srb=<optimized out>, userdata=0x3673a170) at pulsecore/pstream.c:287
5 0x0000ffff873b8bec in srbchannel_rwloop (sr=0x36766ae0) at pulsecore/srbchannel.c:190
6 0x0000ffff87339c70 in dispatch_pollfds (m=0x36670db0) at pulse/mainloop.c:655
7 0x0000ffff87339c70 in pa_mainloop_dispatch (m=m@entry=0x36670db0) at pulse/mainloop.c:898
8 0x0000ffff8733a01c in pa_mainloop_iterate (m=0x36670db0, block=<optimized out>, retval=0xffffd9683030) at pulse/mainloop.c:929
9 0x0000ffff8733a0d8 in pa_mainloop_run (m=m@entry=0x36670db0, retval=retval@entry=0xffffd9683030) at pulse/mainloop.c:945
10 0x0000000000406894 in main (argc=<optimized out>, argv=<optimized out>) at daemon/main.c:1144
Signed-off-by: zhaochengyi <zhaochengyi@uniontech.com>
On the machines with the ucm used, the different input/output devices
often have different pcm stream, so they often belong to different
sources and sinks, this is greatly different from the design of all
devices connected to a codec (without ucm).
For example, on a machine with ucm2 used:
the internal dmic is on source#0
the external mic is on the source#1
the internal spk is on sink#0
the external headphone is on sink#1
Users expect that after plugging the external device, it will become
the active device automatically. The switch-on-port-available could
make it to be the active_port on its own source/sink, but can't make
source/sink to be default_source/sink since the sources/sinks belong
to the same profile (HiFi usually).
If we adjust the source/sink priority according to ucm ports priority,
the device_port.c could handle the default_source/sink changing then.
Usually we set higher priority for external device than internal
device in the ucm.
In order to bring the lowest side effect on the source/sink priority,
I change the ucm priority to units digit first, then add it to the
original priority.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
We met a weird situation on a couple of Lenovo machines and at least
on one Dell machine. First we open the gnome-sound-setting, then
suspend and resume the system, after the system resume back, the audio
devices change to dummy, the audio doesn't work anymore. And pacmd
list-cards shows no available sound card.
Through debugging I found after resume, the alsa receives POLLERR
events and it will call unsuspend to recover the pcm, but at that
moment, the device nodes in /dev/snd/ is not accessible, so the
snd_pcm_open() fails and the pulseaudio unload the module-alsa-card.
Here I add retry and pa_msleep if snd_pcm_open fails, I tested it on
all machines which have this problem, pa_msleep(25) is ok for most of
them, there is only one machine which needs to call pa_msleep(25)
twice, so for safety reason, I set the max retry times to 4.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
