On Friday 26 September 2014 11:39:50 Arun Raghavan wrote: > On 26 September 2014 14:59, Pali Roh?r <pali.rohar at gmail.com> wrote: > > On Friday 26 September 2014 11:00:39 Arun Raghavan wrote: > >> On 26 Sep 2014 14:19, "Pali Roh?r" <pali.rohar at gmail.com> > > > > wrote: > >> > On Friday 26 September 2014 06:55:38 Arun Raghavan wrote: > >> > > On 26 September 2014 03:06, Pali Roh?r > >> > > <pali.rohar at gmail.com> > >> > > >> > 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 <pali.rohar at gmail.com> > >> > > >> --- > >> > > > > >> > > > 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. > >> > > > >> > > http://cgit.freedesktop.org/~arun/pulseaudio/tree/src/m > >> > > 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). 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) :-) Also there are applications which using only alsa pulse wrapper. And these applications needs full rewrite. > 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. 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. So what do you think about it? -- Pali Roh?r pali.rohar at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140926/2db4e86b/attachment.sig>
