On Tue, 2020-03-17 at 16:43 +0100, Pali Rohár wrote: > On Tuesday 17 March 2020 11:23:22 Tanu Kaskinen wrote: > > On Sun, 2020-01-12 at 12:42 +0100, Pali Rohár wrote: > > > On Sunday 12 January 2020 09:21:31 Tanu Kaskinen wrote: > > > > Would you be willing to document the codec negotiation process in the > > > > wiki? > > > > > > What exactly? > > > > The things that you mentioned below: > > * Either side can establish the connection, so it's not obvious what > > things can trigger a connection. For example, what might cause a > > headset to initiate the connection? > > * BlueZ may decide the codec instead of PulseAudio. What logic does it > > use? > > * There are many places with their own defaults. What are these places > > and their codec selection logic? > > > > Maybe these things doesn't affect the UI as I first thought, but it > > would be great to have a reference anyway, so that the system can be > > understood when debugging codec issues. > > Ok. So after implementation of multicodec support would be in > pulseaudio I can document how it works and how it can be configured. Thanks! > > > > I can give you a wiki account. I believe you have already > > > > explained this before in emails, but I've forgotten the details. To me > > > > it would make sense if only the playback side (or the audio gateway for > > > > bidirectional modes) could decide the codec, but I recall the reality > > > > is more complicated, and there were multiple places where the chosen > > > > codec may be remembered. > > > > > > Side which establishing connection choose codec. It does not have to be > > > playback side. And connection establishment is done by calling DBus > > > bluez function, independently of pulseaudio (in most cases desktop > > > bluetooth GUI application do that). So we cannot avoid it. > > > > > > But there are many places which has own defaults. So establishing > > > connection would work without specifying codec and some remembered / > > > default value would be used. > > > > > > > The negotiation details affect the constraints > > > > for UI design. > > > > > > We can do this: When user choose profile, then PA issue command to > > > activate profile with some default codec. User would see in GUI what was > > > chosen and could change if is not happy with it. If he does not care > > > about it he would use default / remembered option and so does not have > > > to choose anything. > > > > Here's my current overall thinking: > > > > Having the six profiles as you suggested is good. > > > > If I understood correctly, you're proposing to make the sub-profiles a > > generic concept rather than a bluetooth specific API. I'm a bit > > hesitant to add an abstraction that doesn't in reality abstract > > anything, because bluetooth is the only user for now and other users > > haven't been suggested. On the other hand, I don't foresee concrete > > problems with this either, so I guess it doesn't really matter. > > Ok. If it simplify things, we can decide that subprofile implementation > would be in bluetooth pa module and therefore bluetooth specific. > > Now the remaining question is: Which API or solution would be used to > implement subprofiles (codec selection) by GUI/CLI tools? Pulseaudio > client <--> server protocol would be needed to extended to support this > kind of subprofile commands. Or messaging API (still not merged) could > be used for this. The messaging API fits better if this is bluetooth specific. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
