This should make it easier for clients to elevate their audio threads to
real time priority without having to dig through much through specific
system internals.
sco_process_render does not unref the memblock when it encounters an error.
This patch fixes the issue. It also changes the return value to 1 in the case
of EAGAIN. Because the data was already rendered and cannot be re-sent, we
have to discard the block.
Because the modified EAGAIN handling prevents the log message about EAGAIN
after POLLOUT from being printed, the log message was moved to
a2dp/sco_process_render().
The rewrite of the thread function does not change functionality much,
most of it is only cleanup, minor bug fixing and documentation work.
This patch also changes the send buffer size for a2dp sink to avoid lags
after temporary connection drops, following the proof-of-concept patch
posted by Dmitry Kalyanov.
Bug-Link: https://bugs.freedesktop.org/show_bug.cgi?id=58746
Additionally the patch changes the fixed latency for HSP playback from 125
to 25 ms. Tests showed that this produces better audio sync, which is
expected as HSP should have smaller latency than A2DP.
The suspend cause isn't yet used by any of the callbacks. The alsa sink
and source will use it to sync the mixer when the SESSION suspend cause
is removed. Currently the syncing is done in pa_sink/source_suspend(),
and I want to change that, because pa_sink/source_suspend() shouldn't
have any alsa specific code.
There are no behaviour changes, the code from almost all the SET_STATE
handlers is moved with minimal changes to the newly introduced
set_state_in_io_thread() callback. The only exception is module-tunnel,
which has to call pa_sink_render() after pa_sink.thread_info.state has
been updated. The set_state_in_io_thread() callback is called before
updating that variable, so moving the SET_STATE handler code to the
callback isn't possible.
The purpose of this change is to make it easier to get state change
handling right in modules. Hooking to the SET_STATE messages in modules
required care in calling pa_sink/source_process_msg() at the right time
(or not calling it at all, as was the case on resume failures), and
there were a few bugs (fixed before this patch). Now the core takes care
of ordering things correctly.
Another motivation for this change is that there was some talk about
adding a suspend_cause variable to pa_sink/source.thread_info. The
variable would be updated in the core SET_STATE handler, but that would
not work with the old design, because in case of resume failures modules
didn't call the core message handler.
When resuming a sink or source, pa_sink/source_process_msg() should be
called only if resuming is successful. pa_sink/source_process_msg()
updates thread_info.state and notifies streams about the new state, but
if resuming fails, there's no state change.
This removes the symdef header generation m4 magic in favour of a
simpler macro method, allowing us to skip one unnecessary build step
while moving to meson, and removing an 11 year old todo!
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 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
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
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.
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.
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).
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.
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 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.
Users may configure the device alias to have characters outside the
ASCII range, so our name cleanup routine was too aggressive. Let's just
make sure that the device description is a valid UTF-8 string.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=98160
This is a rebase of Wim Taymans patch to support the HSP headset role that has
somehow been forgotten. Original patch can be found at
https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-February/023242.html
Rebase and minor changes by Georg Chini.
In addition to the HSP Audio Gateway, also add support for the headset
role in the native bluetooth backend. In this role, pulseaudio is used as
headset.
In the headset role, we create source and sink to receive and send the samples
from the gateway, respectively. Module-bluetooth-policy will automatically load
loopback modules to link these to a sink and source for playback. Because this
makes the source the speaker and the sink the microphone, we need to reverse the
roles of source and sink compared to the gateway role.
In the gateway role, adjusting the sink volume generates a +VGS command to set
the volume on the headset. Likewise, receiving AT+VGS updates the sink volume.
In the headset role, receiving a +VGS should set the source volume and any
source volume changes should be reported back to the gateway with AT+VGS.
A recent patch changed the MTU size from the default value of 48 to the value
returned by getsockopt(). This breaks HSP for some setups. To circumvent the
problem, this patch introduces a boolean parameter "autodetect_mtu" for
module-bluetooth-discover, module-bluez5-discover and module-bluez5-device to
make this use of getsockopt() configurable.
Bug 96741 shows a case where an assertion is hit, because
pa_asyncq_new() failed due to running out of file descriptors.
pa_asyncq_new() is used in only one place (not counting the call in
asyncq-test): pa_asyncmsgq_new(). Now pa_asyncmsgq_new() can fail too,
which requires error handling in many places. One of those places is
pa_thread_mq_init(), which can now fail too, and that needs additional
error handling in many more places. Luckily there weren't any places
where adding better error handling wouldn't have been easy, so there are
many changes in this patch, but they are not complicated.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96741
SW: Pulseaudio 8.0 / BlueZ 5.39
Symptoms:
While disconnecting/reconnecting a paired bluetooth headset (LG HBS750)
audio fails roughly on every other connection.
On a failed connection "pactl list cards" shows the bluetooth device's
card but "Active Profile: off". Issuing "pacmd set-card-profile X
a2dp_sink" makes audio work immediately.
I realized that when this happened, the previous disconnection did not
remove the card, instead it was only configured for "Active Profile:
off" but otherwise left in place.
Upon looking at PA debug logs I saw that the transport for the a2dp_sink
was first set into disconnected state and then into idle state. In
"device_connection_changed_cb()" this causes the
"pa_bluetooth_device_any_transport_connected()" return true and the
module-bluez5-device is not unloaded.
Further investigation shows that this is caused by a race of
module-bluez5-device.c:thread_func() and
MediaPoint1::ClearConfiguration().
When the FD in thread_func() is closed (POLLHUP) an
BLUETOOTH_MESSAGE_STREAM_FD_HUP message is sent into the main thread.
The handler of this message unconditionally sets the transport into IDLE
state. This is a problem if it has already been set into DISCONNECTED
state.
create_card_profile() used to get called separately for HSP and HFP,
so if a headset supports both profiles, a profile named
"headset_head_unit" would get created twice. The second instance would
get immediately freed, so that wasn't a particularly serious problem.
However, I think it makes more sense to create the profile only once.
This patch makes things so that before a profile is created, we check
what name that profile would have, and if a profile with that name
already exists, we don't create the profile.
A couple of Yocto releases (jethro and krogoth) have non-upstream
patches that suffer from this double creation. The patches add
associations between profiles and ports, and those associations use
the profile name as the key. When the second profile gets freed, the
associations between the profile and its ports get removed, and since
the profile name is used as the key, this erroneously affects the
first profile too. Crashing ensues.
BugLink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10018
I want module-alsa-card to set the availability of unavailable
profiles before the initial card profile gets selected, so that the
selection logic can use correct availability information.
module-alsa-card initializes the jack state after calling
pa_card_new(), however, and the profile selection happens in
pa_card_new(). This patch solves that by moving parts of pa_card_new()
to pa_card_choose_initial_profile() and pa_card_put().
pa_card_choose_initial_profile() applies the profile selection policy,
so module-alsa-card can first call pa_card_new(), then initialize the
jack state, and then call pa_card_choose_initial_profile(). After that
module-alsa-card can still override the profile selection policy, in
case module-alsa-card was loaded with the "profile" argument. Finally,
pa_card_put() finalizes the card creation.
An alternative solution would have been to move the jack
initialization to happen before pa_card_new() and use pa_card_new_data
instead of pa_card in the jack initialization code, but I disliked
that idea (I want to get rid of the "new data" pattern eventually).
The order in which the initial profile policy is applied is reversed
in this patch. Previously the first one to set it won, now the last
one to set it wins. I think this is better, because if you have N
parties that want to set the profile, we avoid checking N times
whether someone else has already set the profile.
pa_module_unload() takes two pointers: pa_module and pa_core.
The pa_core pointer is also available via the pa_module object,
so the pa_core argument is redundant
[David Henningsson: Rebased to git HEAD]
Flushing the asyncmsgq can cause arbitrarily callbacks to run, potentially
causing recursion into pa_thread_mq_done again. Because of this; rtpoll which
is cleared in the second iteration is tried to free once again by the first
iteration leading to PA crash.
FSF addresses used in PA sources are no longer valid and rpmlint
generates numerous warnings during packaging because of this.
This patch changes all FSF addresses to FSF web page according to
the GPL how-to: https://www.gnu.org/licenses/gpl-howto.en.html
Done automatically by sed-ing through sources.
In case a transport is currently disconnected and transitions to
idle, that should not count as a "remote hang up" event.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Parse the gain changed AT commands from the headset and fire 2 new
hooks as a result. The device will connect to those hooks and change the
source/sink volumes.
When the source/sink volume changes, set the gain on the microphone or
speaker respectively. Make sure we do nothing if the transport can not
handle the gain changes.
If the transport for the profile doesn't exist, the old behaviour was
to leave cp->available at the default value, which is
PA_AVAILABLE_UNKNOWN, but if there's no transport, the profile should
be marked as unavailable.
This commit adds basic support for devices implementing HSP Headset
Unit, HSP Audio Gateway, HFP Handsfree Unit, HFP Audio Gateway to the
BlueZ 5 bluetooth audio devices driver module (module-bluez5-device).
The code in the "io_fail" section was only used for HUP handling, but
there were jumps to there also from places where reading or writing
failed, because the read/write failure could have been caused by HUP.
This patch simplifies things by checking for HUP condition before
trying to read or write. Now if reading or writing fails, we will
jump to "fail" directly instead of going via the "io_fail" label. As
a result, the "io_fail" label isn't needed any more.
This name is more acurate with regards of what role we're currently
playing and we've already been using it in
pa_bluetooth_profile_to_string() since 449d6cb.
Currently the latency information is being updated based on the encoded
SBC data instead of the decoded PCM data. Fixing this required moving
the timing update to be after the packet has been decoded.
The Nokia E7 running Symbian Belle Refresh seems to generate invalid SBC
packets every few minutes. This causes pulseaudio to disconnect the
stream and log "SBC decoding error (-3)".
If a single packet is bad, pulseaudio should keep playing the stream.
When setting attribute foo, or in this case the card profile, in my
opinion the thing passed to the set_foo() function should be of the
type of foo, not a string identifier that can be used to search for
the actual foo in set_foo().
This is mostly a question of taste, but there's at least some small
benefit from passing the actual object: often the profile object is
already available when calling pa_card_set_profile(), so passing the
card name would cause unnecessary searching when pa_card_set_profile()
needs to look up the profile from the hashmap.
For quite some time now the device driver module doesn't work well
without the discovery module, so for the BlueZ 5 support we'll prevent
the device driver module to be loaded if the discovery module is not
loaded.
