On Tue, 2019-02-12 at 10:14 +0100, Pali Rohár wrote: > On Friday 08 February 2019 21:44:53 Tanu Kaskinen wrote: > > On Tue, 2019-02-05 at 20:35 +0100, Pali Rohár wrote: > > > On Tuesday 05 February 2019 21:22:46 Tanu Kaskinen wrote: > > > > On Mon, 2019-02-04 at 20:28 +0100, Pali Rohár wrote: > > > > > On Monday 28 January 2019 18:50:56 Tanu Kaskinen wrote: > > > > > > On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote: > > > > > > > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote: > > > > > > > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote: > > > > > > > > > On Friday 25 January 2019 11:49:32 Tanu Kaskinen wrote: > > > > > > > > > > On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote: > > > > > > > > > > It's unclear how priority of the codecs (and their parameter > > > > > > > > > > permutations) should be configured, but it seems quite clear that a > > > > > > > > > > "set codec" operation on a specific card would be useful. If the "set > > > > > > > > > > codec" operation is separate from "set profile" operation, then you no > > > > > > > > > > doubt will ask how to implement the client API for this new operation, > > > > > > > > > > and I don't have a very good answer. > > > > > > > > > > > > > > > > > > > > Georg Chini has been working on a new messaging API, which would be a > > > > > > > > > > good fit for this, but that's stalled (I don't remember if it's waiting > > > > > > > > > > for review or a new version of the patches). If you don't want to be > > > > > > > > > > blocked by that, the alternative is to add new "get bluetooth card > > > > > > > > > > info" and "set bluetooth card a2dp codec" commands to the core protocol > > > > > > > > > > (the card info command would be for enumerating the available codecs), > > > > > > > > > > or to add the commands via a new "protocol extension" similar to what > > > > > > > > > > module-stream-restore, module-device-restore and module-device-manager > > > > > > > > > > do. I would be fine with either approach. > > > > > > > > > > > > > > > > > > > > Adding new commands to the core protocol would be somewhat simpler, but > > > > > > > > > > I'm not sure other maintainers are ok with adding bluetooth specific > > > > > > > > > > functionality to the core protocol. > > > > > > > > > > > > > > > > > > All this seems like bluetooth specific. Extending core protocol API for > > > > > > > > > bluetooth specific API means that all applications needs to be extended > > > > > > > > > to support it. > > > > > > > > > > > > > > > > > > So for choosing A2DP codec, it would be needed to extend KDE sound > > > > > > > > > system settings application, Gnome configuration, and also other... > > > > > > > > > > > > > > > > > > I think this is too complicated and needs cooperation with other > > > > > > > > > projects and team. > > > > > > > > > > > > > > > > Well, I disagree about it being too complicated, and there's no need > > > > > > > > for any particular cooperation effort. UIs that want to change the > > > > > > > > codec just need to be updated to take advantage of the new feature. No > > > > > > > > functionality is degraded even if they don't adapt. > > > > > > > > > > > > > > Yes, no functionality is degraded, but no functionality is also added. > > > > > > > And extending UI, logic behind it and so... needs cooperation with other > > > > > > > projects and teams. Without it there is zero benefit for pulseaudio for > > > > > > > ability to switch codecs -- as nobody would use it. > > > > > > > > > > > > Why would nobody use it? At the very least pactl is available. I still > > > > > > don't know what cooperation you're talking about. If you think we > > > > > > should ask the UI developers what they want before we add a new API for > > > > > > choosing the a2dp codec, then that discussion should be had anyway > > > > > > before doing anything else, because your current patches are forcing > > > > > > them to use the card profile API for selecting the a2dp codec. > > > > > > > > > > We need to tell developers of all those application that new pulseaudio > > > > > API is going to be added into libpulse library and that they need to > > > > > extend their existing application to use this API and implement codec > > > > > switching. > > > > > > > > > > We need to do this cooperation, otherwise they would not know that new > > > > > API is being prepared and they need to implement this new functionality > > > > > into their applications, system settings (or where is audio > > > > > configuration implemented). > > > > > > > > > > Otherwise there would be only pactl support (if we implement it) and it > > > > > is really not ideal... > > > > > > > > Ok, so you're mainly worried about the application developers not > > > > knowing about the A2DP codec switching functionality. The functionality > > > > will be announced in the release notes, and we can either rely on users > > > > to report feature requests to the relevant applications, or we can file > > > > those feature requests ourselves. > > > > > > Yes, but this would take more time and developers probably should > > > communicate with us about this API... > > > > Sure, it will take more time. But I think having separate knobs for > > choosing the codec and its parameters it's a better client API in the > > long term than stuffing all the parameter permutations in one long > > profile list. > > Not only it takes more time. Question is also who will implement it? I don't know, I suppose the person who has the time, skills and motivation. Maybe you? (A contribution to pavucontrol would be most welcome.) > Also with argument that codec should not be in profile, we can ask > similar question: Why there is special profile for A2DP and special > profile for HFP? From user point of view the difference is only between > codecs (which is visible in quality of transferred audio). Profiles determine which sinks and sources should be created. HSP/HFP has both a sink and a source, unlike A2DP. Also, the sink that is created by A2DP is different (i.e. has different name) than the one created by the HSP/HFP profile. The sinks used to be the same, but since volume behaves differently between the profiles, it was considered better to have separate sinks and therefore separate volumes for the two profiles. > And when codec would not be bound to profile, how users would know which > codec is currently in use? There needs to be an API to query the state. -- 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
