There are two reasons for this change:
1. If it is a Dell desktop machine with the realtek codec, and there
is no internal microphone on it, there is one physical audio jack
which can support headphone, headset and microphone, but this audio
jack does not have hardware capability to distinguish what is plugged
in, after users plug in a headphone and select headphone from UI
program, the headphone can't output any sound. There are many reasons
for this issue, one of them is the active_port of pa_source is set
to headphone-mic, that means the kernel audio driver will configure
this audio jack to be a microphone jack instead of headphone jack.
If we make the priority of headset-mic a bit higher than headphone-mic,
the headset-mic will be the active_port of pa_source unless users
select the headphone-mic on purpose, then this issue will be fixed.
2. Nowadays, the headset is more popular than traditional microphone,
It is highly possible that users plug in a headset instead of
microphone, it makes sense to make the headset-mic's priority higher
than headphone-mic's.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
module-stream-restore primarily uses the role of a stream for restoring. The sink-inputs
and source-outputs of filters all have role "filter", therefore currently all filters are
treated equally and are restored to the same device and volume.
This patch lets module-stream-restore ignore the streams that connect the filter to the
master.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
These changes are from fedora.zanata.org. The authors are
Sam Friedmann <sfriedma@redhat.com>
Wim Taymans <wim.taymans@gmail.com>
Edouard Duliege <edouard.duliege@gmail.com>
When a filter sink is moving, it's not connected to any master sink, and
therefore it's not connected to any IO thread either. In this situation
trying to move a stream that is connected to the filter sink is likely
to result in crashing, because starting the move involves sending a
message to the IO thread. Sometimes this works by accident (the
asyncmsgq of the filter sink still points to the old master sink's
asyncmsgq), but we really should never attempt it. This patch blocks all
moves where the moving stream is connected to a filter sink that itself
is in the middle of a move.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100277
In sink_put() and source_put(), pa_core_update_default_{sink,source}() was called
before the PA_CORE_HOOK_{SINK,SOURCE}_PUT hook. Therefore module-switch-on-connect
could not correctly determine the old default sink/source if no user default was
set and a sink/source with higher priority than any other sink/source turned up.
This patch corrects the problem by swapping the order of the hook call and the
pa_core_update_default_sink() call.
Additionally it corrects a problem in module-switch-on-connect. If, after the
change above, the new sink/source was the first sink/source to appear, pulseaudio
would crash because module-switch-on-connect assumed that the default sink/source
was not NULL. The patch checks if the default sink/source is NULL and only sets
the new default sink/source in that case.
When a filter is loaded and module-switch-on-connect is present, switch-on-connect
will make the filter the default sink or source and move streams from the old
default to the filter. This is done from the sink/source put hook, therefore streams
are moved to the filter before the module init function of the filter calls
sink_input_put() or source_output_put(). The move succeeds because the asyncmsq
already points to the queue of the master sink or source. When the master sink or
source is attached to the sink input or source output, the attach callback will call
pa_{sink,source}_attach_within_thread(). These functions assume that all streams
are detached. Because streams were already moved to the filter by switch-on-connect,
this assumption leads to an assertion in pa_{sink_input,source_output}_attach().
This patch fixes the problem by reverting the order of the pa_{sink,source}_put()
calls and the pa_{sink_input,source_output}_put calls and creating the sink input
or source output corked. The initial rewind that is done for the master sink is
moved to the sink message handler. The order of the unlink calls is swapped as well
to prevent that the filter appears to be moving during module unload.
The patch also seems to improve user experience, the move of a stream to the filter
sink is now done without any audible interruption on my system.
The patch is only tested for module-echo-cancel.
Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=100065
When sinks are compared during the default sink selection, the active
port's availability is inspected. Therefore, the default sink should be
updated when the active port changes, because the new port may have
different availability status than the old port.
For example, let's say that a laptop has an analog sink with a speaker
and a headphone port, and headphones are initially plugged in, so both
ports can be used[1]. The headphone port is initially the active port.
There's also a null sink in the system. When the headphones are
unplugged, the headphone port becomes unavailable, and the null sink
becomes the new default sink. Then module-switch-on-port-available
changes the analog sink port to speakers. Now the default sink should
change back to the analog sink, but that doesn't happen without this
patch.
[1] Actually we currently mark speakers as unavailable when headphones
are plugged in, but that's not strictly necessary. My example relies on
both ports being available initially, so the bug can't be reproduced
with the current mixer configuration.
When the ofono backend released a tranport during suspend of sink or source, the
transport state was not changed to IDLE. Therefore pa_bluetooth_transport_set_state()
would return immediately when trying to resume. Even though the transport was acquired
correctly, setup_stream() would never be called and the resume failed.
This patch sets the transport state to IDLE when the transport is released. On resume,
the first call to transport_acquire() will be done from the message handler of the
*_SET_STATE message when source or sink are set to RUNNING. This call will only request
the setup of the connection, so setup_stream() cannot be called.
When the transport changes the state to PLAYING in hf_audio_agent_new_connection(),
handle_transport_state_change() is called. Because the sink or source state is already
RUNNING, the pa_{source,sink}_suspend() call will not lead to a state change message
and the I/O thread must be signaled explicitely to setup the stream.
The first setup of the device would also fail, which was only visible when the profile
was restored after connecting the headset. When trying to restore the headset_head_unit
profile, the profile was shortly set to off, so the headset always returned to a2dp.
This patch allows a delayed setup for the headset_head_unit profile, so that the profile
can successfully be restored.
When suspending due to idle timeout the transport will not change its
state, also in case the fd is closed due to POLLERR/POLLHUP events
the release shall check if the fd is still set otherwise it will fail
to be acquired again.
This means something went wrong, which in case of ofono backend it is
probably due to the profile not connecting immediately, but it can be
safely restored in that case the transport is playing which means the
profile has recovered connectivity.
The compiler warned about number_of_frames being possibly used
uninitialized, and on closer inspection I found that it was indeed not
initialized if saved_frame_time_valid is false.
In commit fe70b9e11a "source/sink: Allow pa_{source,
sink}_get_latency_within_thread() to return negative values" the
number_of_frames variable was added as an unsigned version of the l
variable, and number_of_frames partially replaced the l variable. The
replacement should have gone all the way, however. This patch removes
the remaining uses of the l variable and substitutes number_of_frames
on its place, and as a result, number_of_frames is now always
initialized.
It doesn't make sense to use a sink or source whose active port is
unavailable, so let's take this into account when choosing the default
sink and source.
Currently the default sink policy is simple: either the user has
configured it explicitly, in which case we always use that as the
default, or we pick the sink with the highest priority. The sink
priorities are currently static, so there's no need to worry about
updating the default sink when sink priorities change.
I intend to make things a bit more complex: if the active port of a sink
is unavailable, the sink should not be the default sink, and I also want
to make sink priorities dependent on the active port, so changing the
port should cause re-evaluation of which sink to choose as the default.
Currently the default sink choice is done only when someone calls
pa_namereg_get_default_sink(), and change notifications are only sent
when a sink is created or destroyed. That makes it hard to add new rules
to the default sink selection policy.
This patch moves the default sink selection to
pa_core_update_default_sink(), which is called whenever something
happens that can affect the default sink choice. That function needs to
know the previous choice in order to send change notifications as
appropriate, but previously pa_core.default_sink was only set when the
user had configured it explicitly. Now pa_core.default_sink is always
set (unless there are no sinks at all), so pa_core_update_default_sink()
can use that to get the previous choice. The user configuration is saved
in a new variable, pa_core.configured_default_sink.
pa_namereg_get_default_sink() is now unnecessary, because
pa_core.default_sink can be used directly to get the
currently-considered-best sink. pa_namereg_set_default_sink() is
replaced by pa_core_set_configured_default_sink().
I haven't confirmed it, but I expect that this patch will fix problems
in the D-Bus protocol related to default sink handling. The D-Bus
protocol used to get confused when the current default sink gets
removed. It would incorrectly think that if there's no explicitly
configured default sink, then there's no default sink at all. Even
worse, when the D-Bus thinks that there's no default sink, it concludes
that there are no sinks at all, which made it impossible to configure
the default sink via the D-Bus interface. Now that pa_core.default_sink
is always set, except when there really aren't any sinks, the D-Bus
protocol should behave correctly.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=99425
Previously, if front:x didn't work, we would try to use hw:x for analog
stereo output. There's no guarantee that hw:x is an analog output,
however. For example, the Intel HDMI LPE driver uses hw:x for HDMI
output, and PulseAudio incorrectly created analog profiles for that
card, because front:x doesn't work but hw:x does.
This patch changes things so that the analog stereo mapping doesn't any
more use hw:x as a fallback. A separate "unknown stereo" fallback
mapping is added to handle the rare case where hw:x is the only PCM
device that works.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
The percent calculation could overflow in the pa_*volume_snprint*() functions.
For large volumes, volume * 100 can exceed UINT32_MAX.
This patch adds appropriate type casts.
When the volume exceeds PA_VOLUME_MAX in pa_sw_volume_multiply() or
pa_sw_volume_divide(), volume settings are insanely high and the
user should be notified about it.
This patch adds volume clamping to pa_sw_volume_divide() and prints
a warning when the volume is clipped in both functions.
In pa_{source,sink}_new() and pa_{source,sink}_put() the current hardware
volume was miscalculated:
hw volume (dB) = real volume (dB) + soft volume (dB)
was used instead of
hw volume (dB) = real volume (dB) - soft volume (dB)
This lead to a crash in pa_alsa_path_set_volume() if high volumes were
set and the port was changed.
This patch fixes the calculation. Thanks to Tanu for pointing out
the correct solution.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=65520
Several virtual sources and sinks apart from module-echo-cancel also query the master
sink or source to estimate the current latency. Those modules might potentially show
the bug that is described for module-echo-cancel in bug 100277.
This patch checks in the message handlers for the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY
if the master sink or source is valid and returns 0 as latency if not. This is however
not yet sufficient to solve the issue. Additional patches will follow.
When module-echo-cancel is loaded and there is only one sound card, then during a
profile switch, all sinks and sources can become temporarily unavailable. If
module-always sink is loaded, it will load a null-sink in that situation. If
also module-switch-on-connect is loaded, it will try to move the sink-inputs to
the new null-sink. If a sink-input was connected to the echo-cancel sink,
pa_sink_input_start_move() will send a PA_SINK_GET_LATENCY message to the
echo-cancel sink. The message handler will then in turn call
pa_sink_get_latency_within_thread() for the invalid master sink of module-echo-cancel.
This lead to a segfault.
This patch checks in the message handler if the master sink (or source) is valid and
returns 0 if not.
If a HFP audio gateway was connected via the ofono backend, pulse would
segfault during shutdown of the daemon. pa_bluetooth_discovery_unref()
removed the devices and transports before the ofono backend was freed.
Because the ofono backend keeps its own list of transports, transport_free()
was then called during termination of the ofono backend with an invalid
transport. Bug reported by Andrew Hlynskyi.
This patch moves the termination of the ofono and native backends before
freeing the devices.
The 'portable' form factor was currently missing meaning it is not
getting any form-factor priority at all and it would therefore always
be ranked lower then internal devices (which receive 400 form factor
priority). The priority 450 is smaller then 'speaker', based on the
idea that a portable device might have less quality then a dedicated
'speaker' device (some Yamaha amplifiers announce themselves as such).
https://bugs.freedesktop.org/show_bug.cgi?id=100579
The reported latency of source or sink is based on measured initial conditions.
If the conditions contain an error, the estimated latency values may become negative.
This does not indicate that the latency is indeed negative but can be considered
merely an offset error. The current get_latency_in_thread() calls and the
implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
latencies because they do not make sense from a physical point of view. In fact,
the values are truncated twice, once in the message handler and a second time in
the pa_{source,sink}_get_latency_within_thread() call itself.
This leads to two problems for the latency controller within module-loopback:
- Truncating leads to discontinuities in the latency reports which then trigger
unwanted end to end latency corrections.
- If a large negative port latency offsets is set, the reported latency is always 0,
making it impossible to control the end to end latency at all.
This patch is a pre-condition for solving these problems.
It adds a new flag to pa_{sink,source}_get_latency_within_thread() to allow
negative return values. Truncating is also removed in all implementations of the
PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
original behavior is not altered in most cases. Only if a positive latency offset
is set and the message returns a negative value, the reported latency is smaller
because the values are not truncated twice.
Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
for monitor sources because the source gets the data before it is played.
The old code worked incorrectly in several situations. For example,
trying to use the "master" argument wouldn't work, because if
"sink_master" wasn't specified, pa_namereg_get() would pick the default
sink as the master sink.
The latency controller will try to adjust to the configured latency regardless
of underruns. If the configured latency is set too small, it will lead to
periodically occuring underruns. Therefore an underrun protection is implemented
which will increase the target latency if too many underruns are detected.
Underruns are tracked and if more than 3 underruns occur, the target latency
is increased in increments of 5 ms. One underrun per hour is accepted.
The protection ensures, that independent from the configured latency the
module will converge to a stable latency if the configured latency is too
small.
The print_msg argument to update_minimum_latency() had to be re-introduced,
because there is one place where the message should not be logged.
Currently passing parameters to a filter loaded by module-filter-apply is
not possible.
To enable passing parameters to a filter this patch uses an additional property
filter.apply.{MODULE_NAME}.parameters. This way, filters like virtual-surround-sink
and ladspa-sink are fully supported. For example:
paplay file.wav --property=filter.apply=ladspa-sink \
--property=filter.apply.ladspa-sink.parameters="plugin=ladspa \
label=ladspa_stereo control=0"
Currently, module-filter-apply cannot load module-ladspa-sink because filter-apply
provides the argument "sink_master" but ladspa-sink expects "master" instead.
Therefore this patch adds the sink_master argument to module-ladspa-sink.
Additionally, the autoloaded argument was also added.
Currently, module-filter-apply cannot load module-virtual-surround-sink because filter-apply
provides the argument "sink_master" but virtual-surround-sink expects "master" instead.
Therefore this patch adds the sink_master argument to module-virtual-surround-sink.
Additionally, the autoloaded argument was also added.
fltr->name should be freed before freeing fltr. Because filter_free()
can never be called from other places without f set, the pa_assert()
can be removed and filter_free() can be used in process() as well.
When the specified pid no longer exists as a child of the process (since
it was already reaped by the SIGCHLD handler), errno is set to ECHILD, not
to ESRCH.
If source or sink are changed, the current sink input rate may be different
from the default rate. Switch sink input rate back to default to avoid the
influence of the previous combination of source and sink.
During a move sink_input->sink is not valid. This leads to a crash when
sink_input_set_rate() is called from the moving() callback. This patch
fixes the problem.
The previous patch assumed constant port latency offsets. The offsets can
however be changed by the user, therefore these changes need to be tracked
as well. This patch adds the necessary hooks.
Also the print_msg argument was removed from update_minimum_latency() and
update_latency_boundaries() because the message should always be logged.
With the current code, the user can request any end-to-end latency. Because there
is no protection against underruns, setting the latency too small will result in
repetitive underruns.
This patch tries to mitigate the problem by calculating the minimum possible latency
for the current combination of source and sink. The actual calculation has been put
in a separate function so it can easily be changed. To keep the values up to date,
changes in the latency ranges have to be tracked.
The calculated minimum latency is used to limit the configured latency.
The minimum latency is only a "best guess", so the actual minimum may be much
larger (for example for USB devices) or much smaller than the calculated value.
Changes of the port latency offsets are not yet handled, this will be done in a
separate patch.
