This rejigs the update_rate() logic to encompass changes to the sample
spec as a whole, as well as passthrough status. As a result,
sinks/sources provide a reconfigure() method which allows
reconfiguration as required.
The behaviour itself is currently unchanged -- alsa-sink/-source do not
actually implement anything other than rate updates for now (nor are
they ever requested to). This can be modified in the future, to allow,
for example 24-bit output when incoming media supports it, as well as
channel count changes for passthrough sinks.
Another related change is that passthrough status is now part of
sink/source reconfiguration, and we can stop doing a suspend/unsuspend
when entering/leaving passthrough state. So that part is now divided
in two -- pa_sink_reconfigure() sets the sink in passthrough mode if
required, and pa_sink_enter_passthrough() sets up everything else
(this currently means only volumes, but could disable other processing)
for passthrough mode.
The configured adjust time does not match exactly the real adjust time. Also
the adjust time varies. To improve latency estimation use an average of the
measured adjust times instead of the configured value in all calculations.
Since HSP had higher priority than A2DP, the default profile when
connecting a new headset was HSP. To me it makes more sense to default
to high-quality output. We already have some automatic policies to
switch to HSP when it's needed.
I also made the A2DP source and HSP/HFP gateway profiles have lower
priority than the A2DP sink and HSP headset profiles. The A2DP source
and HSP/HFP gateway profiles should only be activated if the remote
device initiates audio streaming, so it makes sense to have lower
priority for those profiles.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=103058
This reverts commit ca63fbc1d8.
I applied the patch too hastily. force-speaker.conf is supposed to be
used only when the alsa mixer doesn't contain any elements that would
indicate the existence of a speaker port, but the reverted patch is a
workaround for a different problem. On the two affected EeePC machines
the Headphone element needs to be unmuted when using speakers. The
analog-output-speaker-always path happens to do that, but that's
unintentional. analog-output-speaker was changed[1] to mute the
headphone output when using the speaker port, and
analog-output-speaker-always should have been changed too, but that was
forgotten.
The kernel driver is buggy if it has a Headphone mixer element that
mutes both headphones and speakers, so this should be fixed in alsa. If
we end up having a workaround in PulseAudio for the broken driver, it
should be implemented with a new profile set and path configuration
files.
[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=22aac4e9fdb3786178f7815a0cb2150f588b1582
This adds a port, card and profile to RAOP sinks to make it
possible to change the latency at runtime (and have it persist)
using pavucontrol or pactl set-port-latency-offset.
Also move the IP:port part of the sink name to the port name.
EAGAIN is used allover the code rather than EWOULDBLOCK
POSIX allows EAGAIN and EWOULDBLOCK to have the same value (and in fact it is)
don't check for EWOULDBLOCK
modules/raop/raop-client.c: In function ‘send_udp_audio_packet’:
modules/raop/raop-client.c:473:41: warning: logical ‘or’ of equal expressions [-Wlogical-op]
if (written < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
^~
modules/raop/raop-client.c: In function ‘resend_udp_audio_packets’:
modules/raop/raop-client.c:528:45: warning: logical ‘or’ of equal expressions [-Wlogical-op]
if (written < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
^~
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Use pa_assert_se() to check return value (pro forma) like everywhere else
Coverity ID: #154313
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
The macro LADSPA_PATH was defined as a list of directories quoted but
without taking into account that the directory names, specially on
Windows, can contain backslashes that need escaping.
This patch removes the quoted from the macro and uses the C preprocessor
to quote it properly using a helper macro.
Pulseaudio tries to pick the best profile (on startup or
hotplugged), the best profile is the profile with the highest
priority which isn't unavailable.
Due to the facts that iec958 ports available status always (?)
is unknown, and that it is generally more likely that a user use
hdmi than iec958, lets prioritze hdmi over iec958.
This patch shift the analog-* mappings +5 and hdmi-* mappings +5.
Use predefined values depending on the server, and make it configurable.
AirPlay is supposed to have 2s of latency. With my hardware, this is
more 2.352 seconds after numerous tests.
Switch from pausing/resuming the smoother to resetting it because the
smoother got stuck returning the same value after an idle/running cycle,
making latency calculation wrong.
This breaks a lot of headsets, so disabling by default. Can be
re-enabled in configuration for specific hardware where it is deemed
necessary.
Also added some debug logging to be able to examine what MTU size is
reported by the device.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102660
Some sound cards don't have any alsa-lib configuration, but they used to
work well enough up to PulseAudio 10. PulseAudio 11 stopped using "hw:0"
for the analog-stereo mapping, and instead defined it as a fallback
mapping without any mixer handling. As a result, switching between
headphones and speakers stopped working without changing the mixer
settings manually at least on Toshiba Chromebook 2. This patch adds the
mixer handling back to the fallback mapping.
I also renamed "unknown-stereo" to "stereo-fallback", because I like
that name more.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=102560
This is basically a copy of module-always-sink but doing the same for
sources. Whenever no source is available, a module-null-source is loaded
and whenever a new source is available again, module-null-source is
unloaded.
By this, anything using a source will automatically be switched to the
null source when the actual source disappears, and back to the actual
source if it appears again.
There are actually two HSP HS UUIDs. My theory is that the second one
was added, because someone was not happy with the old UUID being used
for identifying two different things (the HSP profile as a whole, and
the HS role within the HSP profile). Some headsets only use the new
UUID, and those headsets won't work if we don't recognize the new UUID.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=93898
to_alsa_dB() returns a result rounded to two decimal places (instead of
using integer truncation) to avoid small errors when converting between
dB and volume.
Consider playback at -22 dB (which is supported by ALSA) but results in
the higher level of -21 dB plus software attenuation.
pa_sw_volume_from_dB(-22) = 28172
pa_sw_volume_to_dB(28172) = -21.9997351
to_alsa_dB(-21.9997351) = -2199
ALSA value 106 = -2200
ALSA value 107 = -2100
...
rounding = +1 /* "accurate or first above" */
snd_mixer_selem_ask_playback_dB_vol(me, -2199, rounding, &alsa_val)
alsa_val = -2100
Signed-off-by: Ian Ray <ian.ray@ge.com>
Some modules may only be loaded once, and trying to load them
twice from default.pa makes PulseAudio startup fail. While that could
be considered a user error, it's nicer to not be so strict. It's not
necessarily easy to figure what went wrong, if for example the user
plays with RAOP and adds module-raop-discover to default.pa, which first
works fine, but suddenly stops working when the user at some point
enables RAOP support in paprefs. Enabling RAOP in paprefs makes
module-gconf load the module too, so the module gets loaded twice.
This patch adds a way to differentiate module load errors, and
make cli-command ignore the error when the module is already
loaded.
module-switch-on-port-available didn't do anything when a port changes
its status if the card didn't have any sinks or sources. This was to
avoid bad things during card initialization, but the if condition also
prevented any profile switches away from the "off" profile, because the
card has no sinks or sources when the "off" profile is active.
pa_card nowadays has the "linked" flag that
module-switch-on-port-available could have checked instead, but since it
doesn't make sense to emit port status change events before the card has
been initialized, I added the check in pa_device_port_set_available()
instead.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=101794
It was reported that on a certain USB card, identified as
"0d8c:0102 C-Media Electronics, Inc. CM106 Like Sound Device",
the "PCM Capture Source" element had to be set to "IEC958 In" before
the iec958 input would work.
The iec958-stereo-input.conf file didn't exist before, although the path
was referenced in the default.conf profile configuration file.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=101973
When connecting a headset via the native backend, the transport state was
not updated correctly.
This patch sets the state to PLAYING in transport_acquire() if necessary.
If the description is not updated when moving, the old automatically
generated description will refer to the old master sink after the move,
which is not nice.
Setting the allow_negative flag of pa_{source,sink}_get_latency_within_thread() to true
leads to improved end to end latency estimation and to correct handling of negative port
latency offsets.
There are one headset jack on the front panel of TB16, through this
jack, we have one stereo headphone output (hw:%f,0,0) and one mono
headset-mic input (hw:%f,0,0); and there is one speaker output jack
(hw:%f,1,0) on the rear panel of TB16.
The detail information of the Dell dock TB16:
http://www.dell.com/support/article/sg/en/sgbsdt1/SLN301105
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Currently, if a stream is manually moved to a filter sink or source managed by
module-filter-apply, the stream will be silently re-routed to the master sink
or source, because the filter.apply property is not set on that stream. We can
assume, that the users intention however was to have the stream filtered.
Therefore this patch changes the logic, so that the stream will not be moved
to the master but remains on the filter sink or source. To handle the change
of a property correctly, the filter.apply property must be set temporarily.
An additional property filter.apply.set_by_mfa was introduced to mark those
streams, so that filter.apply can be removed again when the stream moves away
from the filter.
When a phone is connected via bluetooth and switches to HFP, the sinks
and sources will have higher priority than the built-in devices.
Therefore they are chosen as default and module-bluetooth-policy will
incorrectly insert loopback modules that loop the phone back to itself.
This patch fixes the problem by lowering the priority of sink and source
if PulseAudio is in the headset role. The priority is also lowered if the
device is an a2dp source. In both cases it does not make sense to make the
source or sink default unless there is no other sound device available.
Currently pulseaudio crashes with an assertion in pa_rtpoll_item_new_asyncmsgq_read()
or pa_rtpoll_item_new_asyncmsgq_write() if a loopback is applied to a tunnel-new
sink or source, because tunnel-{sink,source}-new do not set thread_info.rtpoll.
The same applies to module-combine-sink and module-rtp-recv.
This patch is not a complete fix for the problem but provides a temporary band-aid
by initializing thread_info.rtpoll properly. The rtpoll created is never run, but
loopback and combine-sink nevertheless work, see comments in the code.
This patch does not work for module-rtp-recv, but using rtp-recv with a remote
sink does not seem to make a lot of sense anyway.
Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=73429
This allows us to restore the default device properly when a
hotpluggable device (e.g. a USB sound card) is set as the default, but
unplugged temporarily. Previously we would forget that the unplugged
device was ever set as the default, because we had to set
configured_default_sink to NULL to avoid having a stale pa_sink pointer,
and also because module-default-device-restore couldn't resolve the name
of a currently-unplugged device to a pa_sink pointer.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=89934
This reverts commit 69c212f8c1.
Reasons:
The original reason for the patch was to work around some issue
regarding the profile not connecting immediately (sorry, I don't really
know the details), but that issue was fixed later by commit 998dfdf4cc,
so the original reason doesn't apply any more.
Automatically changing the profile when the transport state changes to
PLAYING has traditionally been handled by module-bluetooth-policy, and
as far as I can tell, there's no reason to change that.
The assertion is unsafe. It's not guaranteed that the profile change
will always succeed (at least pa_thread_mq_init() can fail due to
reaching the maximum file descriptor limit).
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
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 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.
