On Thu, Oct 17, 2019 at 11:59:57AM +0200, Pali Rohár wrote: > > > > > > > > So... what should applications expects and how they should implement > > > > above decision? > > > > > > Actually the decision should be based on the presence of > > > RegisterApplication method, if that exists then endpoint switching > > > should be supported as well, so has nothing to do the > > > GetManagedObjects API of the bluetoothd. That said RegisterApplication > > > was not made experimental which kind makes 5.51 broken because it > > > would appear that it endpoint objects would be exposed but when in > > > fact there are not, anyway lets finally have the code to use this > > > interface and then we can remove the experimental flag from > > > MediaEndpoint. > > > > Ok, so can pulseaudio do following? > > > > Call RegisterApplication. If success then expects that codec switching > > is possible and via GetManagedObjects exports all available codecs. > > If RegisterApplication fails then fallback to RegisterEndpoint, expects > > that codec switching is not possible and so register only one SBC codec. > > Also can we solve this problem in bluez ASAP? Last released bluez > version is due to that non-experimental API broken and once applications > (e.g. pulseaudio) starts using this new API then A2DP without bluetoothd > -E would be broken. > > I would propose to remove experimental mark for codec switching API and > release a new bugfix version of bluez, so people would not use released > 5.51 broken version... which could prevent breakage of A2DP in future. > +1 It would be nice to get bluez 5.52 released before 5.51 gets released by distros.. -- Pasi
