Hi Pali, On Fri, Jun 7, 2019 at 6:37 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > On Friday 07 June 2019 18:26:02 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > > > > Hello! > > > > > > > > In current git bluez master repository are new features related to A2DP. > > > > E.g. support for codec switching or fallback to other local dbus > > > > endpoints when current selected rejected connection... > > > > > > > > Moreover codec switching support is behind experimental runtime switch. > > > > > > > > For pulseaudio a2dp module I need to do runtime check if above features > > > > are supported by currently running bluez instance (which registered to > > > > dbus org.bluez. It is needed to ensure that pulseaudio does not > > > > introduce regression for older bluez version without above new A2DP > > > > features. > > > > > > > > But currently I have not found any way how to detect if bluez supports > > > > codec switching or if it has support for trying another local SEP for > > > > connection. > > > > > > > > So, could you please export e.g. bluez version as dbus property? And > > > > also property if codec switching is supported and enabled by that > > > > experimental flag? > > > > > > Hello, I would like to ask for some possibility to export these > > > information. Without them it is not really possible to have stable > > > implementation which would work with both old and new bluez version. > > > > I wonder what you are talking about since your changes do have checks > > for when endpoints are detected, > > But this does not work as endpoints are available on DBus only when A2DP > connection is active. I already asked to export them always (even when > A2DP is not connected). > > Main problem is that when profile switching is not available, there > should be registered only one A2DP codec (SBC in automatic quality) as > changing is not possible. This is to prevent introducing any regression > or having registered codec which would not work correctly. I fill like repeating myself over and over, but here it goes again, endpoints are not supposed to initiate connection which is the reason why in PA the card is created only when a profile is connected, and no we are not going to introduce feature like this to counter bugs where HFP is left connect while A2DP isn't, etc. It is very important to note that while we are caching the remote endpoints we never assume they are valid before we connect and confirm they are still available. > > isn't that enough to detect if one can switch codecs or not? > > Yes, this could be enough... but endpoints on DBus must be always > available, not only when A2DP profile is connected. Not gonna happen. > > This logic used to work just fine last time I tested it. > > -- > Pali Rohár > pali.rohar@xxxxxxxxx -- Luiz Augusto von Dentz
