The transport might have disapeared exactly before acquiring, so we
should avoid an assertion failure, in this case inside the function
pa_bluetooth_discovery_get_by_path().
The HFGW source should be consistent with the sink by not setting the
"phone" intended role.
Even though setting this role seems to make sense strictly speaking, the
rest of the codebase doesn't handle this well. Therefore, the audio
coming from a Bluetooth phone can be routed back to the same device.
Make code more readable by introducing the helper function
bt_transport_is_acquired(). This also adds assertions to check whether
the internal state is consistent.
Previously, sink_input_kill_cb would cleanup u->sink an then unload the
module. However, during module unload, both save_state and dbus_done
tried to use u->sink, causing a segfault or assertion failure.
The segfault is easy to reproduce: Load module-equalizer-sink and then
press ctrl-C to terminate pulseaudio.
This commit removes the u->sink cleanup in sink_input_kill_cb, since
u->sink will be cleaned up by the module's pa__done as well (after it
has been used).
Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
Nowadays, we are using more hashmaps and other things, than we did
before. Therefore, I often get the "flist is full (don't worry)"
message. This change should avoid that message. I was unable to find
any significance in increase of memory footprint from this change.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Interestingly, the name is properly matched even though there
is no paths/iec958-stereo-input.conf file.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
This check was valid before we introduced per-source-output volumes, so
dropping it now. Thanks to Alban Browaeys <prahal@yahoo.com> for
catching this.
During initialization, the approach avoids having a needless short
period of corked state in case the sink is suspended, by always creating
the source-output corked and uncorking it immediately afterwards when
the sink is not suspended.
During initialization, the approach avoids having a needless short
period of corked state in case the source is suspended, by always
creating the sink-input corked and uncorking it immediately afterwards
when the source is not suspended.
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".
