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

[Arun Raghavan]

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/tree/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.

>> 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.

>> > 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.

> 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.

> 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