Commits 323195e305 ("switch-on-port-available: Switch to headphones on
unknown availability") and d83ad6990e ("module-alsa-card: Drop
availability groups with only one port") broke switching from headphones
to speakers when headphones are unplugged. switch_from_port() selects
speakers, whose availability is unknown and availability group is unset,
and then calls switch_to_port(). The new logic in switch_on_port()
unintentionally blocked that switch.
This patch moves the problematic logic from switch_to_port() to
port_available_hook_callback() where it doesn't interfere with
switch_from_port().
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1043
Since not all users will have environments that asks what they plugged
in when their hardware supports TRRS inputs but don't have impedance
sensing, let's emulate our previous default behaviour of enabling the
headphone port at least.
This can likely be improved so users can configure the module to select
for the device they are most likely to plug in (so an option to enable
just the microphone, or headphones+headset-mic ports).
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1028
HDMI jacks are configured like this:
[Jack HDMI/DP]
append-pcm-to-name = yes
The pa_alsa_jack.name field is then "HDMI/DP" and pa_alsa_jack.alsa_name
is set to "HDMI/DP,pcm=3 Jack" or similar. If we compare the name fields
of HDMI paths, they appear to use the same jack element even though they
are different in reality, so all HDMI ports got incorrectly assigned to
the same availability group.
Previously they were set once per mapping, which caused the numbering to
restart from 1 for every mapping, so ports were incorrectly assigned to
the same group.
Almost all reports from users, I have seen in last years, were not valid.
The report is also printed when the system scheduler does not wake
the pulseaudio thread in the right time. Users are not able to distinguish
between slow machine and the real problem.
Move the log level from 'error' to 'debug' for those messages.
The right fix should be to measure the time between the call invocation and
return to determine (and skip) the scheduling problems, but it is another
extra code just to debug things.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Since the RTP timestamp is converted to time units and back, a small
error can creep up, which then results in a single frame error in where
we place the buffer in the output memblockq. This results in minor
glitches, so we check for and eliminate the error.
With GStreamer 1.18, the old behaviour of storing the capture time in
DTS is gone (which is reasonable, since the semantics really don't
match). So instead, we get a capture timestamp when the buffer is being
pushed from udpsrc. This should eventually move into udpsrc, and the
timestamp should come from the cmsg instead of the clock.
We still fallback to the DTS if the meta isn't available, as the meta
might be dropped in older versions of rtpL16pay due to a bug.
Hashmap loaded_device_paths contain objects holding keys to entries, and
these objects must be alive while map is emptied.
Reorder freeing this hashmap before destroying device objects to fix
crash on exit.
If write_entry fails to store new entry in database, next time we can try creating new entry again.
With DBUS enabled this will create another dbus entry for same name leading to crash inserting duplicate into dbus_entries map.
Fix this by checking if dbus entry exists in dbus_entries map before creating it.
Fixes: #974
Although the hdmi-output is in well_known_descriptions[] table,
the hdmi device names are indexed (hdmi-output-0), thus there
is no match to assign the proper type automatically.
This patch puts the correct hdmi type to all relevant hdmi
configuration files.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Add missing import of util.h. This fixes a build failure with the
Xcode 12 command line tools which manifests as follows:
error: implicit declaration of function 'pa_thread_make_realtime'
is invalid in C99 [-Werror,-Wimplicit-function-declaration]
Ref https://trac.macports.org/ticket/61107
The current implementation for RTP send isn't optimised for sending MTU
bytes of data like rtp-native. For eg. if MTU is 1280 bytes and we have
to send 1276 bytes, two packets are send out one of 1268 bytes and other
of 8 bytes. Sending out a packet of 8 bytes has a significant overhead
and we should be sending MTU bytes of data.
Fix this by accumulating MTU bytes of data and sending data only on
accumulation of MTU worth of data.
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>
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.
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.
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.
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>
It's possible for mdev to be NULL. In this case, an assert is taken
in pa_alsa_open_mixer_by_name() with debug builds, and a crash with
release builds. However, it's possible to bypass this trouble by taking
the error path if mdev is NULL.
Reported-by: Jarkko Sankala <jarkko.sankala@offcode.fi>
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
Previously avoid_resampling was always false unless the sink or source
implementation explicitly configured the variable. The null sink doesn't
explicitly configure it, so it didn't switch the sample rate as
expected when avoid_resampling was enabled.
This change means that also sinks that don't support rate switching can
have avoid_resampling set to true, but I think that's fine, because
pa_sink_reconfigure() doesn't try to do anything if the reconfigure()
callback isn't set.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/923
