Keeping the SBC check separate means we can keep the SBC_LIBS/CFLAGS
separate, which is cleaner. Thanks to Jan Steffens for pointing out that
this was broken (SBC_* wasn't actually changed to match the configure
change).
This reverts commit da5078e5c7.
Let device module figure out the priority based on the state of the
profiles.
Note that most likely all profiles will be in PA_BT_AUDIO_STATE_CONNECTED
state so 'Off' will be the initial profile then it is up to the policy
module to switch to the most suitable profile.
pa_sink_input_seek() calculates output lenth (slength) and
corresponding input length (ilength). During an underrun, the function
generates slength bytes of silence and adds ilength to the
underrun_for value. However, the ilength value may be shortened to
match resampler limits, and there's no corresponding adjustment to
slength. Thus, the length of the generated silence is longer than
resampler output would have been, and underrun_for should be increased
by more than the limited ilength. This error makes the user-visible
since_underrun field in struct pa_timing_info too small. Fix by using
the original value calculated before limiting in this case.
The problem that the comment mentions doesn't actually
exist, because when the sink latency is changed to a smaller
value, the sink implementor will request the required
rewind.
Add support for hfgw card profile in module-bluetooth-policy, just like
a2dp_source is handled.
In this case also the sink needs to be connected using module-loopback.
Instead of focusing on a2dp_source only, prepare the module to support
several profiles. It will be possible to enable/disable each of them
using module arguments.
Property bluetooth.protocol did make a distinction between A2DP sink and
source roles but on the contrary did not separate HFP roles (headset vs
gateway). For consistency, they should both behave similarly.
This automatically fixes another incosistency: the HFGW (or HSP) sink
was set to bluetooth.protocol="sco", while the source was set to "hsp".
There is no use for this distinction, since the protocol (including the
role) is the same.
On ARM, pa_object has less strict alignment requirements
than e.g. pa_sink and pa_source, so when pa_object is cast
to pa_sink, the compiler thinks that it's unsafe. In this
case, however, the pointer given to pa_sink_ref() was a
pa_sink pointer to begin with, so casting it first to
pa_object and then back to pa_sink is entirely safe.
This particular source of warnings is extremely annoying,
because this message is printed for any compilation unit
that includes sink.h, source.h or any other header that
defines a class, and the message tends to get printed
multiple times for one compilation unit:
In file included from ./pulsecore/source-output.h:37:0,
from ./pulsecore/source.h:49,
from ./pulsecore/sink.h:40,
from ./pulsecore/core.h:50,
from daemon/daemon-conf.h:31,
from daemon/cmdline.h:25,
from daemon/cmdline.c:38:
./pulsecore/sink-input.h: In function 'pa_sink_input_ref':
./pulsecore/sink-input.h:245:1: warning: cast increases required alignment of target type [-Wcast-align]
Profile a2dp_source, just like any other card profile, should have
state guards when the profile is being changed. If the BlueZ interface
is not connected, the profile should be set to "off".
