[pulseaudio-discuss] [PATCH v9 0/8] Bluetooth A2DP codecs

Fri Apr 26 08:20:26 UTC 2019

Hi Pali,

On Thu, Apr 25, 2019 at 8:03 PM Pali Rohár <pali.rohar at gmail.com> wrote:
>
> On Thursday 25 April 2019 18:54:05 Pali Rohár wrote:
> > On Thursday 25 April 2019 18:51:49 Pali Rohár wrote:
> > > On Thursday 25 April 2019 19:43:28 Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > >
> > > > On Thu, Apr 25, 2019 at 2:42 PM Luiz Augusto von Dentz
> > > > <luiz.dentz at gmail.com> wrote:
> > > > >
> > > > > Hi Pali,
> > > > >
> > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár <pali.rohar at gmail.com> wrote:
> > > > > >
> > > > > > On Thursday 25 April 2019 13:28:16 Pali Rohár wrote:
> > > > > > > On Thursday 25 April 2019 14:19:15 Luiz Augusto von Dentz wrote:
> > > > > > > > These seems to work great, I can even switch on the fly the profiles
> > > > > > > > and after a short delay it switches without a problem, there is one
> > > > > > > > issue related to reconnecting though:
> > > > > > > >
> > > > > > > > https://gist.github.com/Vudentz/40f10e85fb860083958edae67093f016
> > > > > > > >
> > > > > > > > With BlueZ remembering the last used endpoint (aptX) it seems the
> > > > > > > > policy ignores that and reverts to highest priority (SBC UHQ),
> > > > > >
> > > > > > Relevant lines:
> > > > > >
> > > > > > D: [lt-pulseaudio] bluez5-util.c: Transport /org/bluez/hci0/dev_94_20_53_2E_08_CE/sep5/fd26 available for profile a2dp_sink_aptx
> > > > > > ...
> > > > > > D: [lt-pulseaudio] card.c: a2dp_sink_aptx availability unknown
> > > > > > ...
> > > > > > D: [lt-pulseaudio] card.c: off availability yes
> > > > > > I: [lt-pulseaudio] card.c: bluez_card.94_20_53_2E_08_CE: active_profile: a2dp_sink_sbc_uhq2
> > > > > > D: [lt-pulseaudio] module-bluetooth-policy.c: Looking for A2DP profile activated by bluez for card bluez_card.94_20_53_2E_08_CE
> > > > > > I: [lt-pulseaudio] card.c: Created 5 "bluez_card.94_20_53_2E_08_CE"
> > > > > >
> > > > > > We got information that sep5 is activated with fd26 and it corespondent
> > > > > > to profile a2dp_sink_aptx. And on next lines we see that profile has
> > > > > > unknown availability -- which means that it is possible to switch to
> > > > > > that codec/profile, but it is not activated yet. On next lines we see
> > > > > > that module-bluetooth-policy is trying to find "a2dp_*" which has
> > > > > > availability "on", but there is no one. So initial profile stay
> > > > > > a2dp_sink_sbc_uhq2 which was chosen as default by card.c.
> > > > > >
> > > > > > So problem is why a2dp_sink_aptx profile has unknown availability even
> > > > > > it is activated? It should have "on" availability. And then policy
> > > > > > choose it as initial.
> > > > >
> > > > > Right, looks like the state is not correct since it has a fd already
> > > > > it should have been marked available.
> > > >
> > > > Problem seems to be that we need to set the transport state to playing
> > > > since we introduce the following code:
> > > >
> > > >     if (cp->available == PA_AVAILABLE_NO &&
> > > > u->support_a2dp_codec_switch && pa_bluetooth_profile_is_a2dp(profile))
> > > >         cp->available = PA_AVAILABLE_UNKNOWN;
> > > >
> > > > That means every A2DP profile will be set to unknown including even if
> > > > they have no transport yet
> > >
> > > That is truth. But if there is a transport then availability is YES.
> > >
> > > Availability NO is used when it is not possible to activate transport
> > > because it is unsupported (e.g. A2DP not connected or when bluez does
> > > not support profile switching).
> > >
> > > > so now we have to set the initial transport to playing
> > >
> > > How it should help? I do not see reason now...
> > >
> > > Anyway, I was not able to reproduce your problem, basically I always had
> > > availability for activated profile set to YES.
> >
> > Now I see it. PA_AVAILABLE_YES is returned only for
> > PA_BLUETOOTH_TRANSPORT_STATE_PLAYING.
> >
> > So for PA_BLUETOOTH_TRANSPORT_STATE_IDLE we also get
> > PA_AVAILABLE_UNKNOWN and therefore module-bluetooth-policy does not know
> > which transport is activated.
> >
> > Cannot we get transport state in module-bluetooth-policy? Seems that
> > this is the right direction.
>
> Currently we have following mapping:
>
> PA_BLUETOOTH_TRANSPORT_STATE_DISCONNECTED --> PA_AVAILABLE_NO
> PA_BLUETOOTH_TRANSPORT_STATE_PLAYING --> PA_AVAILABLE_YES
> PA_BLUETOOTH_TRANSPORT_STATE_IDLE --> PA_AVAILABLE_UNKNOWN
>
> Plus PA_AVAILABLE_NO is changed to PA_AVAILABLE_UNKNOWN when pulseaudio
> can activate that transport via bluez codec switch API as described
> above.
>
> PA_PORT_AVAILABLE_YES is defined as:
> This port is available, likely because the jack is plugged in.
>
> PA_PORT_AVAILABLE_NO as:
> This port is not available, likely because the jack is not plugged in.
>
> And PA_PORT_AVAILABLE_UNKNOWN as:
> This port does not support jack detection
>
> Seems that PA code and applications skips profiles with PA_AVAILABLE_NO
> and do not allow to use it. So above change to PA_AVAILABLE_UNKNOWN
> seems like a good idea.
>
> But why idle/suspended transports have PA_AVAILABLE_UNKNOWN? Should not
> it be PA_AVAILABLE_YES? Because transport is activated and can be used.
> It is known that connection is working.

That has different meaning in HFP, for A2DP when we got a transport it
really means that it can be connected so I guess setting it to playing
state is the correct thing to do.

> > > > which hopefully it is just a matter doing the
> > > > following changes (not tested):
> > > >
> > > > diff --git a/src/modules/bluetooth/bluez5-util.c
> > > > b/src/modules/bluetooth/bluez5-util.c
> > > > index 4e4ab0cb8..429914328 100644
> > > > --- a/src/modules/bluetooth/bluez5-util.c
> > > > +++ b/src/modules/bluetooth/bluez5-util.c
> > > > @@ -1837,6 +1837,7 @@ static DBusMessage
> > > > *endpoint_set_configuration(DBusConnection *conn, DBusMessage
> > > >      t->acquire = bluez5_transport_acquire_cb;
> > > >      t->release = bluez5_transport_release_cb;
> > > >      pa_bluetooth_transport_put(t);
> > > > +    pa_bluetooth_transport_set_state(t, PA_BLUETOOTH_TRANSPORT_STATE_PLAYING);
> > > >
> > > >      pa_log_debug("Transport %s available for profile %s", t->path,
> > > > pa_bluetooth_profile_to_string(t->profile));

I testes this change it seems to work properly, though I have an
assert when I use a different headset which does support apt-X HD:

https://gist.github.com/Vudentz/0d6b6f2ad08524db69a3e223e26bc80d

-- 
Luiz Augusto von Dentz