[pulseaudio-discuss] [PATCH] bluetooth: Add support for automatic switch between hsp and a2dp profiles

[Pali Rohár]

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>