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

Tue Sep 30 04:24:06 PDT 2014

On Tuesday 30 September 2014 12:49:11 you wrote:
> On 26 September 2014 19:12, Pali Rohár <pali.rohar at gmail.com> 
wrote:
> > On Friday 26 September 2014 15:17:00 Arun Raghavan wrote:
> >> On 26 Sep 2014 15:45, "Pali Rohár" <pali.rohar at gmail.com>
> > 
> > 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/tre
> >> > > >> > > e/s rc/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).
> >> 
> >> You would set the environment variable in the desktop file,
> >> so normal launch would use it.
> > 
> > Modifying desktop files which are in /usr/ is to up
> > administrator of system not to user...
> > 
> > And still this does not solve problem with x sessions (like
> > ksmserver for KDE4).
> 
> This would be done at the distro level, if needed. Again note
> that this is the _last_ option you'd want to use.
> 

This is not easy to fix and probably this is not possible to fix. 
Because env variables are not stored... But yes I agree that this 
is last option, but also last option should at least work 
somehow...

> >> 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.
> > 
> > Good, this is important!
> > 
> >> > 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.
> > 
> > parec does not set it. And this is just first random app
> > which I checked.
> 
> I don't believe parec should. Or that any non-VoIP application
> should either. HSP (which runs at 8kHz) is _terrible_ for
> general purpose recording. We should not make it available
> for that purpose.
> 

And I think if I connected my bluetooth headset I want to use it 
instead all other input and output sources. Why should otherwise 
I connected wire-less headset with microphone?

> >> > 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
> > 
> > So, what do you want to do with applications which does not
> > set media.role? And what do you want to do with older
> > version of
> 
> Get them to set the media role.
> 

Older versions will not set media role automatically. So user 
must use some hack (e.g. that env variable), but user must know 
that something like that exists.

> > applications which did not set media.role?
> 
> Get them to make a release with media.role set.
> 
> This is a small set of applications, a lot of which already
> set this.
> 

Yes, new versions of applications could be released with 
media.role set so everything will work.

But this means that *very* pulseaudio application should set 
media.role so we will know that application do *not* want to use 
microphone.

For applications which do not set media.role we know nothing.

> > What is bad in my solution?
> 
> That only VoIP applications should really be using it, and the
> only good way to know an application's voip streams is for
> them to be tagged by the application.
> 
> -- Arun

I disagree. Once I connected my bluetooth headset (which has also 
microphone) I want to use only sink/source with my headset. And 
not combination of output to bluetooth, input from internal mic 
and so... This will only confuse other users who wants to use 
bluetooth headset, but PA decide that you do not want to that...

-- 
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/20140930/36ba207e/attachment.sig>