On Friday 26 September 2014 12:15:01 Pali Roh?r wrote: > 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? Arun, what about this blacklist code for source_output streams? if media role is set: if is "phone" --> do not ignore otherwise --> ignore if resampler method is peaks --> ignore if no client is assigned --> ignore if sink is monitor --> ignore otherwise --> do not ignore It will work correctly when all applications have set value of PA_PROP_MEDIA_ROLE correctly and otherwise blacklist heuristic will be used (which should work in all other normal cases). -- 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/8e10b45b/attachment-0001.sig>
