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

[Arun Raghavan]

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

You would set the environment variable in the desktop file, so normal
launch would use it.

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.

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

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20140926/45905e75/attachment.html>