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.
BlueZ 4 is no longer supported by BlueZ community for a long long time,
also by moving to BlueZ 5 it should make it even more clearer that
BlueZ 4 is no longer an option.
Attempt to use Acquire method if available since it directly returns
the fd in the reply or an error if that the connection could not be
created while Connect offer neither of these and depend on
NewConnection to deliver the fd.
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.
It was reported that PulseAudio causes error messages in syslog from
dbus-daemon:
Jan 14 04:51:32 gentoo dbus-daemon[2492]: [system] Rejected send message, 2 matched rules; type="error", sender=":1.15" (uid=1000 pid=2864 comm="/usr/bin/pulseaudio --start --log-target=syslog ") interface="(unset)" member="(unset)" error name="org.bluez.MediaEndpoint1.Error.NotImplemented" requested_reply="0" destination=":1.1" (uid=0 pid=2670 comm="/usr/libexec/bluetooth/bluetoothd ")
The default policy on the system bus is to not let any method call
replies through if they have not been requested, and apparently
bluetoothd doesn't want replies to the Release() call.
This also changes the reply type from error to normal reply. The "not
implemented" error didn't make sense to me. We don't do any cleanup in
the Release() handler, probably because there's nothing to do. If there
is some cleanup that we should do, then it's a serious bug not to do it.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=104646
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
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>
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
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.
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.
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.
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 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
The function can only fail if there's not enough memory available, and
if that happens, the convention in PulseAudio is to abort.
CID: 1353106, 1353108, 1353140
There were two bugs in the old logic. The first one:
If a device has two profiles, the old code would start the wait timer
when the first profile connects, but when the second profile connects,
the timer would not get stopped and the CONNECTION_CHANGED hook would
not get fired, because the code for that was inside an if block that
only gets executed when the first profile connects. As a result,
module-bluez5-device loading would always be delayed until the wait
timeout expires.
The second bug:
A crash was observed in device_start_waiting_for_profiles(). That
function is called whenever the connected profile count changes from 0
to 1. The function also has an assertion that checks that the timer is
not running when the function is called. That assertion crashed in the
following scenario with a headset that supports HSP and A2DP:
1. First HSP gets connected. The timer is started.
2. Then HSP gets disconnected for some reason. The timer is still
running.
3. Then A2DP gets connected. device_start_waiting_for_profiles() is
called, because the connected profile count changed from 0 to 1 again.
The timer is already running, so the assertion fails.
First I thought I'd remove the assertion from
device_start_waiting_for_profiles() and just restart the timer on the
second call, but then I figured that when the device returns to the
"everything disconnected" state in step 2, it would be better to stop
the timer. The purpose of the timer is to delay the notification of the
device becoming connected, but if the device becomes disconnected during
the waiting period, the notification doesn't make sense any more, and
therefore the timer doesn't make sense either.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100237
The auto_switch argument was added in PulseAudio 10.0. In that release
the argument type was boolean. The type was changed to integer in commit
3397127f00. This patch adds backwards compatibility so that old
configuration files won't break when upgrading PulseAudio to 11.0.
With headset=auto it is possible that AG devices are connected and handled
via the native backend when ofono is started. Because the HS role will then
be disabled in the native backend, AG devices must be disconnected and any
future connections will be handled by ofono.
This patch changes the behavior of the headset=auto switch for module-bluez5-discover.
With headset=auto now both backends will be active at the same time for the AG role and
the switching between the backends is only done for the HS role.
headset=ofono and headset=native remain unchanged.
This allows to use old HSP only headsets while running ofono and to have headset support
via pulseaudio if ofono is started with the --noplugin=hfp_ag_bluez5 option.
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.
Issue: When HFP/HSP profile is used with certain BT chipsets, the
audio sounds heavily distorted, with very slow playback full of noise.
During recording, the samples are dropped and it distorts the recorded
audio samples.
The root cause of both the issues are related to the fixed MTU sizes
in the PA stack, which is 48 bytes. Here, the BT chipset CC256x had
180 bytes MTU and it was being under-utilized and the rate at which
the samples were being accepted where not matching the expected rate,
and hence the distortion.
Solution: The appropriate solution to this problem is by reading the
MTU size of the SCO socket using getsockopts dynamically.
BugLink: http://bit.ly/2gDpGPv
BugLink: http://bit.ly/2hQsARK
Not all VOIP applications (specially those which use alsa) set media.role to
phone. This means we need some heuristic to determinate if we want to switch
from a2dp to hsp profile based on number and types of source output (recording)
streams.
And also some people want to use their bluetooth headset (with microphone) as
their default recording device but some do not want to because of low quality.
This patch implements optional heuristic which is disabled by default. It is
disabled by default to not break experience of current pulseaudio users because
heuristic cannot be optimal. Heuristic is implemented in module-bluetooth-policy
module and decide if pulseaudio should switch to a hsp profile or not. It checks
if there is some source output with pass all these conditions:
* does not have set media.role
* does not use peak resample method (which is used by desktop volume programs)
* has assigned client/application (non virtual stream)
* does not record from monitor of sink
And if yes it switch to hsp profile.
By default this heuristic is disabled and can be enabled when loading module
module-bluetooth-policy with specifying parameter auto_switch=2
Because it is disabled by default nobody will be affected by this change unless
manually change auto_switch parameter.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
This fixes a crash that happens if the bluetooth headset is the only
non-monitor source in the system and the last "phone" stream dies.
When the stream dies, the native protocol calls pa_source_output_unlink()
and would call pa_source_output_unref() next, but without this patch,
things happen during the unlinking, and the unreffing ends up being
performed on a stream that is already freed.
pa_source_output_unlink() fires the "unlink" hook before doing anything
else. module-bluetooth-policy then switches the headset profile from HSP
to A2DP within that hook. The HSP source gets removed, and at this point
the dying stream is still connected to it, and needs to be rescued.
Rescuing fails, because there are no other sources in the system, so the
stream gets killed. The native protocol has a kill callback, which again
calls pa_source_output_unlink() and pa_source_output_unref(). This is
the point where the native protocol drops its own reference to the
stream, but another unref call is waiting to be executed once we return
from the original unlink call.
I first tried to avoid the double unreffing by making it safe to do
unlinking recursively, but I found out that there's code that assumes
that once unlink() returns, unlinking has actually occurred (a
reasonable assumption), and at least with my implementation this was not
guaranteed. I now think that we must avoid situations where unlinking
happens recursively. It's just too hairy to deal with. This patch moves
the bluetooth profile switch to happen at a time when the dead stream
isn't any more connected to the source, so it doesn't have to be
rescued or killed.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97906
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.
Bluez5 uses different profile names as bluez4, so we need to check for
a2dp_sink and headset_head_unit too for bluez5 support.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
