On Friday 26 April 2019 12:06:08 Tanu Kaskinen wrote: > On Thu, 2019-04-25 at 19:03 +0200, Pali Rohár 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@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. > > > > 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. > > If I recall correctly, that's because opening the audio link may fail > even if the profile is connected. I think a device can have connections > established with multiple other devices simultaneously, but it might > not be able to stream audio with more than one device at a time. Hm.. This is a good point. So it is better to not touch availability. -- 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
