Brings things in line with the autotools build, and adds ALSA mixer
paths and profile-sets into the meson build system as well.
The module installation path is also now customisable.
Pulseaudio SBC codec defines that audio samples are in PA_SAMPLE_S16LE
format which is little endian. But libsbc library expects audio samples by
default in host endianity which is big endian on big endian system. So SBC
support on big endian system is broken. To fix this problem tell libsbc
library that audio samples are in little endian to match PA_SIMPLE_S16LE
sample format.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91359
Remove dead code and replace numeric bitpool values by macro definitions.
Maximal bitpool value in fill_capabilities() was reduced from 64 to 53
(SBC_BITPOOL_HQ_JOINT_STEREO_44100) because default_bitpool() already set
maximal value to 53.
This patch does not change SBC behavior as maximal bitpool was already
limited to 53. So it is just clean up.
This patch introduce new modular API for bluetooth A2DP codecs. Its
benefits are:
* bluez5-util and module-bluez5-device does not contain any codec specific
code, they are codec independent.
* For adding new A2DP codec it is needed just to adjust one table in
a2dp-codec-util.c file. All codec specific functions are in separate
codec file.
* Support for backchannel (microphone voice). Some A2DP codecs (like
FastStream or aptX Low Latency) are bi-directional and can be used for
both music playback and audio call.
* Support for more configurations per codec. This allows to implement low
quality mode of some codec together with high quality.
Current SBC codec implementation was moved from bluez5-util and
module-bluez5-device to its own file and converted to this new A2DP API.
If one device tries to use PulseAudio to send audio over A2DP to another
device with bluez-alsa, that doesn't work because PulseAudio uses an
incorrect RTP payload type and bluez-alsa checks that the RTP payload
type is correct. According to the A2DP spec, the payload type should be
set to a number between 96 and 127.
Fixes: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/591
I can't promise that the logic is *exactly* the same as the logic
currently in use with the autotools, but it seems correct to me.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Please notice that the bluez5 version seems wrong in the dependency
declaration: `>= 4.x`, while we're talking about version 5.
The ofono part will need to be made optional when we start to work on
the meson_options file.
I follow the current configure.ac to define 'HAVE_BLUEZ', but it looks
like this part would benefit from a bit of rework. Setting HAVE_BLUEZ
when we have dbus+sbc sounds weird, there's probably a better name for
this variable.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Now that both backend-native and backend-ofono can coexist and
backend-ofono is always loaded, even on systems without oFono, failing
to register with org.ofono is not necessarily an error.
This lowers the failure message log level from error to info.
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
