On Friday 26 April 2019 12:01:15 Tanu Kaskinen wrote: > On Thu, 2019-04-25 at 18:54 +0200, 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@xxxxxxxxx> wrote: > > > > > Hi Pali, > > > > > > > > > > On Thu, Apr 25, 2019 at 2:35 PM Pali Rohár <pali.rohar@xxxxxxxxx> 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. > > Yes, I think module-bluetooth-policy should look at the transport > states directly, if that provides better information than the profile > availability. Yes, code which choose initial profile should really look at transport state. But this is not possible in module-blueooth-policy as transport state is private member of module-bluez5-device. I will move that code which choose initial profile into module-bluez5-device. Really it should be there as it is up to the module itself to decide which is the best initial profile. Other modules (based on user settings) may override it. But initial setting should be done by bluez which knows which transport is already activated. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
