In some cases, the I/O connector functionality can be shared
and we cannot determine the proper purpose automatically.
We just know that something was inserted to the jack.
Introduce a group identifier (a simple string - unique
per group) which helps to determine the proper ports
for the application. The user interface may be used
to set the wanted behaviour.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
There is some case that multiple ucm devices share an amixer Jack
like "Headphones", "Headset" and "Mic2" share the "Headphone Mic Jack",
When the Jack state is changed, the module-switch-on-port-available
will process them in the order they are in the jack->ucm_devices, and
the last device will decide the final setting.
But usually users put priority for those devices and expect the
final setting is based on the highest priority device if there is no
other policies like manual selection. So here do some change to store
the ucm_devices according to their priority (from low to high).
For example, we have ucm devices definition like below (ucm2):
SectionDevice."Mic2" {
Comment "Headphones Stereo Microphone"
...
Value {
CapturePriority 200
...
}
SectionDevice."Headset" {
Comment "Headset Mono Microphone"
...
Value {
CapturePriority 300
...
}
}
Without this patch, the final setting is based on Mic2, after applying
this patch, the final setting is based on the Headset (with higher
priority than Mic2).
Signed-off-by: Hui Wang <hui.wang@canonical.com>
There were three maybe-uninitialized warnings when building with
Autotools (for some reason I don't see these with Meson):
modules/raop/raop-sink.c: In function ‘thread_func’:
modules/raop/raop-sink.c:543:16: warning: ‘intvl’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (intvl < now + u->block_usec) {
^
In file included from ./pulsecore/macro.h:270,
from ./pulsecore/cpu-x86.h:25,
from ./pulsecore/cpu.h:23,
from ./pulsecore/core.h:26,
from modules/raop/raop-sink.c:48:
./pulsecore/log.h:129:28: warning: ‘check_timing_count’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define pa_log_warn(...) pa_log_level_meta(PA_LOG_WARN, __FILE__, __LINE__, __func__, __VA_ARGS__)
^~~~~~~~~~~~~~~~~
modules/raop/raop-sink.c:404:14: note: ‘check_timing_count’ was declared here
uint32_t check_timing_count;
^~~~~~~~~~~~~~~~~~
modules/raop/raop-sink.c:500:27: warning: ‘last_timing’ may be used uninitialized in this function [-Wmaybe-uninitialized]
pa_usec_t since = now - last_timing;
^~~~~
I moved the intvl variable initialization out of the for loop, because
it looked like the variable value is supposed to be remembered between
the iterations. I don't know if the variable declaration (without
initialization) in the beginning of the loop caused the compiler to
touch the variable between iterations, probably not, but I'm pretty sure
that's undefined behaviour.
Other than that maybe-undefined behaviour, these compiler warnings may
be false positives, since the variables are initialized when u->first is
true.
I initialized the three variables in to the same value as what is used
when resetting them when u->first is true. I didn't test these changes,
but they look safe to me.
Prior to commits f899d5f466 and
f62a49b8cf, GNOME's sound settings
overwrote the routing for all entries in the stream-restore database
when selecting a device. Now we prevent that from happening (see the
aforementioned commits), but the old overwritten settings can still be in
the database after updating to PulseAudio 14.0, and they can cause
problems, as documented here:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/832
We can't distinguish between devices set by GNOME's sound settings
and devices set by the user, so this patch discards all old device
settings, even though that is going to cause PulseAudio to forget routing
settings for many users. This is less bad than keeping the incorrect
routing settings in the database, because it's difficult for users to
figure out how to fix the situation when e.g. speaker test tones go to
the internal speakers no matter what device is selected as the default,
whereas old manual configuration can be restored restored by doing the
manual configuration again. Also, it's probably more common to have at
some point changed the default device in GNOME's sound settings than it
is to have any manual per-stream routing settings.
This is disabled by default, because this causes data loss, but
distributions that use GNOME are recommended to enable this with
the --enable-stream-restore-clear-old-devices (Autotools) or
-Dstream-restore-clear-old-devices=true (Meson) build option.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/832
pa_namereg_is_valid_name() will hit an assertion if the name string is
NULL. Maybe it would make sense to change pa_namereg_is_valid_name() so
that it would return false on NULL, but I didn't want to change the
function semantics at this time.
e->device and e->card can be NULL even when device_valid and card_valid
are set to true if the database contains bad data.
I ran into this crash while developing new code, I haven't seen the
crash in the wild.
Storing the version in the entry struct is pointless. We should always
write entries using the current version. When we encounter older
versions when reading, those need to be converted to the current version
anyway, because all code that uses the entry struct assumes that the
data is stored according to the current version semantics.
We're currently at the first version of the database entries, so
currently there's no version conversion happening. I have a patch that
will increment the entry version, so this is preparation for that.
In case the local UDP port is blocked by a firewall by default, send
an initial timing packet so the connection tracking will accept the
response packages.
Otherwise, the connection will fail with an 'RTSP/1.0 500 Internal
Server Error' after some timeout.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/840
- remove duplicate mixer initialization in sink
- use the similar mixer initialization for source like for sink
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The UCM device must be activated using the pa_alsa_ucm_set_port()
call on boot (the sink creation time). In case when the
mixer controls are not defined for the application in the
UCM configuration, the mixer_handle is NULL.
Call the pa_alsa_ucm_set_port() before the mixer_handle check.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Support for multiple codecs needs to use a new Bluez API which pulseaudio
does not implement yet.
So register explicitly only SBC codec which is provided by pulseaudio A2DP
codec API.
It's completely normal to not have explicit channel configuration for
stereo devices. In fact, the ALSA developers actively avoid configuring
the channels for stereo devices.
I also dropped the word "duplex" from the messages, because "stereo
duplex" implies bidirectionality, but most devices use one direction
only.
Currently, when the master of a virtual source is moved, the change of the
asyncmsgq is not propagated to other attached virtual sources. This leads
to a crash when the original master source is no longer available.
This patch fixes the issue by modifying the moving callback to propagate the
change to attached virtual sources.
Virtual sinks show a similar bug but that will be fixed in a different patch
series.
The memblockq stores data in the virtual sink format, not in the master
sink format. The wrong sample spec caused a crash when the virtual sink
rendered data whose length was not divisible by the sink input frame
size.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/786
The request_rewind() callback of the uplink sink called
pa_sink_process_rewind(), which is not allowed. Things are supposed to
happen so that first a rewind is requested, and then during the next
rtpoll loop the sink will process the request. Calling
pa_sink_process_rewind() during the request phase caused a crash.
Having a request_rewind() callback is completely unnecessary, because
it's only useful for forwarding the request to a downstream sink. In
this case there is no downstream sink.
I also set max_rewind to 0, because the sink doesn't support rewinding.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/775
If a channels argument is passed module-jackdbus-detect, it is passed to both
module-jack-sink and module-jack-source when those are started. This is a
problem if you want a different number of input channels from output channels.
In particular, if you want more of one than you physically have of the other,
it will fail. This commit adds separate source_channels and sink_channels
arguments to be able to specify the channels arguments to module-jack-source
and module-jack-sink separately. The combined channels argument is kept for
backwards compatibility and will be used as a default for source_channels and
sink_channels if either of them is omitted.
module-jackdbus-detect documents the channels argument as optional and "if
omitted, the sink wil use the number of physical output port and the source
will use the number of physical input ports registered in the JACK server."
However, although it would correctly omit the channels argument to
module-jack-sink and module-jack-source if its channel argument was omitted,
its argument validation was broken to consider omitting channels an error.
This commit properly validates the channels argument so omitting it is
accepted.
As the comment says, switching to HDMI automatically often causes
problems. Commit bae8c16bfa
("switch-on-connect: Do not ignore HDMI sinks") enabled switching to
HDMI earlier. It was known already then that HDMI monitors don't
necessarily have speakers on them, but I accepted the patch on the
basis that module-switch-on-connect acts only if the card profile is
switched to HDMI, so if switching to HDMI is wrong, then already the
profile switch should cause problems. I didn't think of the case where
the default sink is on some other card, in which case switching the
profile on the HDMI card doesn't cause problems by itself.
I don't want to revert bae8c16bfa, because João needs to be able to
configure their systems to automatically switch to HDMI. Instead, this
patch utilizes the new blacklisting feature in module-switch-on-connect
to blacklist HDMI sinks by default. Switching to HDMI can be enabled by
setting the blacklist modarg to an empty string or something that
doesn't match HDMI sinks.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/749
The ALSA mixer can be opened multiple times (especially for UCM
in the probe). This adds a simple mixer cache to prevent
multiple open calls.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
This patch adds the autoreconnect feature to the raop module.
This is mainly to be used in a server context, but can be used
also in a desktop usage context.
With autoreconnect feature, the raop module behaves like this:
- At initialisation or in case of the RTSP TCP connection lost, it
tries to reconnect every 5 seconds
- In case of any fatal error, it tries to reconnect every 5 seconds
- In UDP mode, if no timing packets received anymore for a long time,
RTSP connection is closed, then it tries to reconnect..
- After reconnection, once RTSP session has been established again,
playing is resumed automatically.
- When the connection is not established yet (or loss), the sink
behaves like a null sink. In the source code I called it "autonull",
even if autonull is set to autoreconnect param value, it could be
split into two different params.
This is just invalid. It results to an error in almost all cases.
The hw:<number> scheme is sufficient to get the right card mixer.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Remove the implicit rule. It is perfectly ok to have the jack with
the same name for another I/O in the driver. Trust only the
value obtained from UCM.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
The UCM library is used to get the fallback values from the verbs
and the defaults section. There is no reason to duplicate this code
inside application.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
When users select an input device from gnome-control-center UI, the
source of this input device will be set to the
configured_default_source and the default_source, these actions are
expected, but after these actions, the gnome-control-center will call
extension_cb() to modify the entries in the database, let all stream
entries to bind the source users select, this is not correct since the
source is default_source now.
This is a temp fix for this issue, after gnome-control-center fixes
this problem, this patch should be reverted.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
