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>
fac_table[] lacks of PA_SUBSCRIPTION_EVENT_CARD item. This will cause
pulseaudio crash when it tries to dump the PA_SUBSCRIPTION_EVENT_CARD
event when DEBUG is defined.
Signed-off-by: Libin Yang <libin.yang@intel.com>
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
libpulsecore is not supposed to depend on the client library.
Removing the dependency caused build failures, which are fixed by adding
more stuff to libpulsecommon.
- 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>
Since the .pot file can be automatically generated, it hasn't been
included in the git repository so far. However, we're planning[1] to
start using Fedora's Weblate translation service, and it requires the
.pot file to be in the repository.
[1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/785
The Zanata version is more recent, and there haven't been other changes
to upstream than the fixes in a15cde4179.
I modified the Zanata version to include those fixes.
The Zanata version is more recent, and there don't seem to be many
changes that would be lost in our upstream version since 2012 (based on
the file header, the Zanata version was probably in sync with master
some time in 2012).
Merged with this command, which takes new translations from the Zanata
version, but doesn't take changed translations, except when they clear
the fuzzy flag from a translation:
msgcat --use-first po/ca.po po/ca.po.zanata -o po/ca.po
I also manually copied new translator names to the header comment. I
didn't update the header key/value section, but here are the interesting
bits from the Zanata version:
"POT-Creation-Date: 2015-10-06 16:57+0200\n"
"PO-Revision-Date: 2019-07-25 10:42+0000\n"
"Last-Translator: Robert Antoni Buj Gelonch <rbuj@fedoraproject.org>\n"
"Plural-Forms: nplurals=2; plural=(n != 1)\n"
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.
When running under systemd from its `.service` file, the daemon is
started with `--daemonize=no`. This means that the default logging
target is `stderr` (see the documentation for `--log-target` in
`pulse-daemon.conf(5)`). That works fine, but results in all the
structured logging data from the `pa_log()` calls being thrown away and
not making it into the journal.
In order to preserve structured logging data, and hence make the
messages in the journal a little more useful (for example, allowing the
user to filter by message priority), explicitly pass
`--log-target=journal` in the `.service` file. This should always be
appropriate because the journal should always be used with systemd.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This updates things based on changes in the templates that we use. Also
pins the ref in the template repo so that our build does not break when
the template parameters change.
This does mean that we should likely periodically check the ci-templates
repo, but this seems to be better than the build breaking unexpectedly.
gcc10 can effectively emit single precision registers if right
operand modifier constraint is not in use
This results in assembler rejecting the code
/tmp/ccEG4QpI.s:646: Error: VFP/Neon double precision register expected -- `vtbl.8 d3,{d0,d1},s8'
/tmp/ccEG4QpI.s:678: Error: invalid instruction shape -- `vmul.f32 d0,d0,s8'
Therefore add %P qualifier to request double registers sinece 'w' could
mean variable could be stored in s0..s14 and GCC defaults to printing out s0..s14.
Note those registers map to d0..d7 also.
Output generated is exactly same with gcc9, and it also now compiles
with gcc10
Its not documented well in gcc docs and there is a ticket for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84343
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Currently pa_{sink,source}_move_streams_to_default_{sink,source}() check the
availability of the old sink or source. The sink or source is only marked as
unavailable if the active port of a sink or source is not available.
Therefore sinks or sources without port are always considered available,
even if they are in the process of being unlinked and streams are not
rescued.
This patch removes the availability check because it is unnecessary. The
functions are only called if the sink or source becomes unavailable or if
the default sink or source changes, therefore the default_sink_changed or
default_source_changed argument can be used as an indicator if the old
sink or source is still present. In the case that the old default sink or
source becomes unavailable, the function will be called twice, once when
the default sink or source changes and once when the old sink or source
is unlinked.
pactl has these commands, too. Use the same order as the
man page, except the undocumented 'help'. Note that the commands are
sorted alphabetically when completed anyway, though
that can be disabled since Bash 4.4
(https://unix.stackexchange.com/q/215937/111181)
The zsh completions already support set-default-sink and
set-default-source.
On certain types of filesystem (especially NFS appliances which support
multiple operating systems), the user's home directory may report as
being owned by root rather than the user, yet still permit the user to
create and modify files normally (which will be owned by them).
Our users have home directories hosted on a NetApp storage appliance
which uses mixed-mode ACLs but where the home directory is set up with
NTFS ACLs at the top level. This means they have the expected effective
permissions, but the ownership reports as root. This could also be the
case if the filesystem were using NFS4 ACLs or similar.
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.
