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

[Pali Rohár]

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>