After applying the commit 19e34d8d5b, the speakers could be set to
active port and could output sound when headphone is plugging in. But
it introduced a regression on some old machines, on them there are
only one mute and one volume control shared between speakers and
headphone, pulseaudio can't mute the speaker standalone when the
headphone is playing sound. In such a case, it needs to count on
alsa auto-mute to mute the speaker by setting pinctl to 0x0.
To fix this regression and meanwhile not to impact the fix of the
commit 19e34d8d5b, Boris proposed a good idea in the issues#1297,
based on that idea, I wrote this patch and validated it on a physical
machine:
- After booting up, the speaker is the active output port, in this
case, the auto-mute is disabled and speakers' Pin-ctls: 0x40: OUT
- plugging a headphone, the headphone is the active output port, in
this case, the auto-mute is enabled and speakers' Pin-ctls: 0x00:
- keeping headphone plugged, use pacmd to change the active port to
speaker, the auto-mute becomes disabled and speakers' Pin-ctls:
0x40: OUT
BTW, the patch will not bring any impact to the systems using the ucm
in pulseaudio, that is to say, it will not impact most modern laptops.
Thanks to Boris Gjenero to propose the idea of the fix.
Fixes: 19e34d8d5b ("alsa-mixer: disable the Auto-Mute once the system has speaker")
Closes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1297
Signed-off-by: Hui Wang <hui.wang@canonical.com>
pa_module_load API's return value is integer which is
enum pa_error_code_t with minus such as -PA_ERR_IO
if the module loading is failed.
pa_cli_command_load gets a return value of pa_module_load
as pa_error_code_t which is wrong.
Minus integer value could not covert to enum which is defined
equal or larger than 0 so that pa_cli_command_load would
recognize the return value as larger than 0 if pa_module_load
return value (integer) is minus.
To fix this issue, I modified return value check logic
of pa_module_load API.
As same as pa_module_load's return type, integer would be used
to check if module load is failed in pa_cli_command_load
and the return value would be compared with minus.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/3801
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/814>
My log files get completely clobbered by this; thousands of lines of:
Jan 18 18:14:44 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:15:39 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:15:39 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:16:34 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:16:34 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:17:29 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:17:29 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:18:25 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:18:25 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:19:20 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
Jan 18 18:19:20 pulseaudio[29946]: [pulseaudio] backend-native.c: Dock Status: undocked
Jan 18 18:20:15 pulseaudio[29946]: [pulseaudio] backend-native.c: Battery Level: 50%
This seems like it should be a debug log, not a notice.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/810>
The pa_alsa_ucm_set_port() function is passed both a mapping context and
a device port, and both of these refer to their respective UCM device.
While switching over to having one port per mapping per UCM device, I
expected both of these to be the same device struct, so added an assert
checking so.
This assertion gets triggered when we have multiple UCM verbs declaring
the same UCM device name. The root cause here is that the ports' UCM
device references are set once while creating the ports for the card, so
they happen to be those of a specific verb and may not match those from
a different UCM verb's profiles' mappings.
Solving the root cause necessitates a larger refactor. What we actually
assume here is that name of the UCM device is same for both the port and
the UCM context, which ends up always true in practice. For now, replace
the assert with a check and error.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/802>
Some versions of the ALSA libraries run into a segmentation fault when
we query a UCM device/modifier status without first setting a UCM verb.
It's not a reasonable thing to do anyway, so check for this case and
return an error. Also do the check in other helpers.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/801>
When we connect Lenovo XT99 bt headset in the Ubuntu 22.04, this
headset could only work in A2DP profile, couldn't work in HFP profile
with a high chance.
This headset supports mSBC, after pulseaudio replies "+BCS:2" to
headset, we expect to receive a "AT+BCS=2\r" from the headset, but
with a high chance, it will receive 2 AT commands in a buffer like
this "AT+CHLD=?\rAT+BCS=2\r", and we also observed other 2 AT commands
in a buffer like this "AT+NREC=0\rAT+CGMI?\r".
Here we don't suppose there is only one AT command in a buffer, we
will find each command by the delimiter "\r" and handle each command
by sequence.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/804>
When `pwd.h` header is not available (i.e. not using glibc) and environment
variables are not set (e.g. running via `env --ignore-environment`) client
library would crash due to uninitialized variable in `pa_get_home_dir()`.
Add missing initialization to fix that.
Fixes: #3792
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/800>
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>
