On 26 Sep 2014 15:45, "Pali Rohár" <<a href="mailto:pali.rohar@gmail.com">pali.rohar@gmail.com</a>> wrote: > > On Friday 26 September 2014 11:39:50 Arun Raghavan wrote: > > On 26 September 2014 14:59, Pali Rohár <<a href="mailto:pali.rohar@gmail.com">pali.rohar@gmail.com</a>> > wrote: > > > On Friday 26 September 2014 11:00:39 Arun Raghavan wrote: > > >> On 26 Sep 2014 14:19, "Pali Rohár" <<a href="mailto:pali.rohar@gmail.com">pali.rohar@gmail.com</a>> > > > > > > wrote: > > >> > On Friday 26 September 2014 06:55:38 Arun Raghavan wrote: > > >> > > On 26 September 2014 03:06, Pali Rohár > > >> > > <<a href="mailto:pali.rohar@gmail.com">pali.rohar@gmail.com</a>> > > >> > > > >> > wrote: > > >> > > > On Wednesday 24 September 2014 19:08:55 Pali Rohár > wrote: > > >> > > >> With this patch module-bluetooth-policy > > >> > > >> automatically switch from a2dp profile to hsp > > >> > > >> profile if some application want to start > > >> > > >> recording. > > >> > > >> > > >> > > >> By default a2dp profile is used for listening music, > > >> > > >> but for VOIP calls is needed profile with microphone > > >> > > >> support (hsp). So this patch will switch to hsp > > >> > > >> profile if some application want to use microphone > > >> > > >> and after it release it profile is switched back to > > >> > > >> a2dp. So this patch allows to use bluetooth > > >> > > >> microphone automatically without need of user > > >> > > >> interaction. > > >> > > >> > > >> > > >> Signed-off-by: Pali Rohár <<a href="mailto:pali.rohar@gmail.com">pali.rohar@gmail.com</a>> > > >> > > >> --- > > >> > > > > > >> > > > And with this patch a2dp profile could be preferred > > >> > > > and has higher priority then hsp. Because a2dp has > > >> > > > better audio quality and when recording is needed my > > >> > > > patch for module-bluetooth-policy will switch to > > >> > > > hsp. What do you think about it? > > >> > > > > >> > > I'm not in favour of an exception-list-based approach > > >> > > (too much of a moving target). I'd written something > > >> > > similar in the past based on the media role. I'd > > >> > > prefer something like this since it allows us to take > > >> > > action based on what the stream is meant to be doing, > > >> > > rather than having a blanket policy that may or may > > >> > > not make sense. > > >> > > > > >> > > <a href="http://cgit.freedesktop.org/~arun/pulseaudio/tree/src/m">http://cgit.freedesktop.org/~arun/pulseaudio/tree/src/m</a> > > >> > > odu les/ module-profile-switcher.c?h=bluetooth > > >> > > > > >> > > The intention when we last discussed on the list wast > > >> > > to integrate this into module-bluetooth-policy (the > > >> > > patch predates merge of m-b-p). > > >> > > > > >> > > -- Arun > > >> > > > >> > This approach depends on that output stream set by > > >> > application will have correct PA_PROP_MEDIA_ROLE. So > > >> > basically will not work with any existing application. So > > >> > this is useless for me and for other people too. > > >> > > >> Why not fix said applications? Exposing this metadata > > >> correctly allows several things, such a automatic routing, > > >> echo cancellation/noise suppression, AGC. > > >> > > >> The fix can be made via code or starting the app with an > > >> environment variable set. > > >> > > >> -- Arun > > > > > > Backward compatibility. There still will be non trivial set > > > of applications without PA_PROP_MEDIA_ROLE. Plus there are > > > more closed source applications which you cannot modify. > > > And starting application with some special ENV does not > > > change anything. Still > > > > Does not change anything? You can set a property on all > > streams created by an app using the environment variable. > > > > There are applications which using x sessions (e.g all KDE > applications). And env variables are not stored. > > So solution with env is working only after first application > start (not after logout-login). You would set the environment variable in the desktop file, so normal launch would use it. Note that this is only the approach to take if modifying the app is a complete non option. > Also what is easier? Open xterm, set new env, start application? > Or start application clicking on icon and clicking on icon > "switch from a2dp to hsp"? For normal users it is second option. > Maybe for power user first option. > > So your solution with env is in my opinion only for power users. > All other users who will not know about new special ENV will be > again forced to use manual switch -- so your solution really does > not change anything. > > > > is needed user interaction and it is easier to switch a2dp > > > profile to hsp as opening xterm, setting ENV and then > > > starting application. Plus applications with using > > > pulse-alsa wrapper will never set that PA_PROP_MEDIA_ROLE. > > > > The solution above applies to the ALSA pulse plugin > > applications too. > > > > > > So I think exception list is only possible solution without > > > modifying existing applications. > > > > > > Or do you want to modify *ALL* existing applications which > > > exists? > > > > All VoIP applications, yes. > > > > Ok, starts with skype as this is application is most popular (in > my opinion) :-) Skype already sets this. Has been doing so for years. > Also there are applications which using only alsa pulse wrapper. > And these applications needs full rewrite. This would be a case to consider the env option I mentioned, either via setenv() or desktop file. We are not talking about a massive number of applications here. > > As I mentioned before, there is good reason for applications > > to provide metadata for the types of streams they are > > creating, and I'd rather have a proper solution in place than > > an overreaching heuristic. > > > > -- Arun > > Yes, there is good reason for it -- I understand. But pulseaudio > does not force applications to provide these data and also there > are lot of applications which do not provide these data. > > And I still think that inventing something which will be broken > (by design!!!) by older versions of applications is not good > idea. This is a solution we've had for a while and a number of applications use it already. > I think that my solution with blacklist is better. It can be > easily extended by one condition for *new* applications which > sets PA_PROP_MEDIA_ROLE. > > And if you fix all existing pulseaudio applications then my auto > switch code just do nothing, so it does not break new code for > PA_PROP_MEDIA_ROLE. > > And if some older application connects to pulseaudio (without > PA_PROP_MEDIA_ROLE) then you will have set correct bluetooth > profile. I still disagree with your solution. Applications can and should be providing stream type metadata and we should be implementing policy based on that. -- Arun