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

[Tanu Kaskinen]

On Sun, 2014-11-02 at 14:13 +0100, Pali Rohár wrote:
> On Sunday 02 November 2014 13:44:53 Tanu Kaskinen wrote:
> > On Fri, 2014-10-31 at 14:22 +0100, Pali Rohár wrote:
> > > On Friday 31 October 2014 13:40:57 Tanu Kaskinen wrote:
> > > > On Fri, 2014-10-31 at 13:07 +0100, Pali Rohár wrote:
> > > > > Ok, what about adding new bool parameter to this module
> > > > > (which will be off by default) to use also heuristic
> > > > > when application does not specify media.role?
> > > > 
> > > > Do you have a real use case (not something that you are
> > > > able to imagine, but something that either you or someone
> > > > else really needs)? I'm hesitant to accept any more
> > > > heuristics than really necessary, because this is not how
> > > > I think routing policy "should" be implemented, but the
> > > > way I think routing policy "should" be implemented takes
> > > > so much work that it doesn't make sense to ask you to do
> > > > it.
> > > 
> > > Yes I have real use case. I'm using alsa based application
> > > for voice calls and obviously it does not (and cannot) set
> > > media.role because it is not pulse application.
> > 
> > Here's how I'd like to solve the "can't set media.role"
> > problem: the application should ship a configuration file
> > that tells PulseAudio how to recognize the application's
> > streams (by the executable name probably), and what the media
> > role should be for those streams.
> 
> Open source pulse client application can be patched (and if 
> patches will be accepted) and then *new* versions of application 
> will set correct media.role. There could not be problems.
> 
> Problem is with *older* version of pulse application and with 
> *all* alsa application.

Why would it be a problem with all alsa applications? Usually we cope
just fine if they don't have media.role set. So far only the "phone"
role has been identified as very important.

Anyway, the idea of applications installing a configuration file (not
the .desktop file, that's a different scheme) allows users to create
that configuration file themselves for old applications.

> Sorry but I do not think that application 
> which targets only alsa will accept some patches "because 
> pulseaudio developers invented something new..." (yes, this is 
> what people using only alsa think about pulseaudio). I think you 
> should know that that there are and still will be people who do 
> not like pulseaudio and will never use it because alsa is enough 
> for them.
> 
> I do not like idea to forcing users and application developers to 
> use something which was invented by other projects and does not 
> target original approach... (like this adding pulseaudio hacks 
> into pure alsa applications which do not have equivalent of 
> media.role).

If an alsa application has many users that use PulseAudio, and those
users would like the application to install a tiny configuration file to
make the application work better, I think the application developer
would be unreasonable to not accept a patch that adds that file. It's
possible that such developers exist, and that would be covered by the
repository of configuration files for those cases where the files aren't
shipped along with the application for whatever reason.

I interpret the latter paragraph so that you as a user would be somehow
offended if whatever alsa voip application you're using would install a
PulseAudio specific file to indicate that its streams have the "phone"
role. Is that a correct interpretation, and if so, can you explain why
you would care?

> > Hmm, actually in most cases it's enough if the application
> > ships a .desktop file and sets the role there. IIRC Arun
> > advocated this approach. There may still be cases where the
> > separate configuration file approach works better (e.g. when
> > the application will never ship a .desktop file for some
> > reason).
> > 
> 
> If application is in active development and supports native pulse 
> library I think that developers should accept your patches (but 
> they have a right to refuse it for whatever reason). For older 
> unpatched version you still need some list.
> 
> Problem with desktop files is that you cannot target terminal 
> applications.

True, but I said "in most cases". Do you know any terminal applications
that would need to set media.role to "phone" (or something else)?

> > > I and also there are other people who want to use bluetooth
> > > microphone as primary recording device. But when if no
> > > application want to record sound it is the best to switch
> > > back to a2dp mode for better output quality. And manually
> > > switching profiles is pain.
> > > 
> > > Another use case is when there is no sound card with
> > > recording capability or it is integrated sound card is
> > > configured to output-only mode, because user does not have
> > > any microphone plugged in.
> > 
> > For these cases I think the option in module-bluetooth-policy
> > is ok.
> > 
> 
> Ok. Anyway is there some support for turning this option on/off 
> at runtime (without unloading and load plugin again)?

Not much. It's possible to define protocol extensions so that
applications can communicate with modules using libpulse. See for
example module-device-manager for how it can be done (I wouldn't take
too much inspiration from its client API, though...).

> > > > So yes, adding another parameter to
> > > > module-bluetooth-policy should be fine if there's real
> > > > need for it. In a separate patch, please, because I'd
> > > > like to merge the
> > > > by-media-role-only heuristic first.
> > > 
> > > Ok. I will send move heuristic into new patch and send two
> > > v3 patches.
> 
> So look at v3 patches now. Auto switch by default use only 
> media.role=phone and with module parameter "switch=2" use also 
> heuristic.

I will have a look when I have time. Note that there are other patches
in the queue too:
http://www.freedesktop.org/wiki/Software/PulseAudio/PatchStatus/

(Your patches will be inserted after "core: Add a per-stream
flat-volumes flag" based on the date of the first submission.)

Could we have something more descriptive than "switch=2"? For example:
"switch_to_hsp_on_phone_stream=true/false" and
"switch_to_hsp_on_any_stream=true/false".

-- 
Tanu