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

[Pali Rohár]

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

Do what you think... These are just my opinions to yours 
solutions.

I certainly will not use any black/white listing based on argv[0] 
or something similar, because it is broken by design.

> If the application
> developers for some reason refuse to do this, or if the
> application isn't maintained any more, we could add the
> configuration file ourselves to a repository containing that
> sort of configuration files (I'd prefer an external git
> repository to keep the clutter out of the main PulseAudio
> repository, but I don't feel too strongly about that).
> 
> We'd then need a module that reads those configuration files.
> module-augment-properties could perhaps be extended to do
> that.
> 
> 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.

> > 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)?

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

-- 
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/20141102/ee6ab792/attachment.sig>