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

Mon Nov 3 06:43:56 PST 2014

On Sunday 02 November 2014 18:13:43 Tanu Kaskinen wrote:
> 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.
> 

Sorry, I mean all alsa applications which want to record voice.

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

Yes, but somebody must to do it. And for someone is easier to 
open sound configuration application and switch profile manually 
as learning some new language/format_of_configuration_file which 
will be used by pulseaudio.

Problem with white or black listing is that it never match 
everything correct and somebody must maintain it.

Also for pure alsa applications which using pulseaudio (via 
wrapper), pulseaudio can only read applications argv[0] and based 
on device name. There is no property like client name (correct me 
if I'm wrong). And I'm really sceptical for using argv[0] as 
identifier...

> > 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 do not know numbers of of those applications or developers or 
users, but I know lot of people who do not install pulseaudio and 
also do not accept any pulseaudio specific patch to own 
applications.

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

In specific scenario: I as developer of voip alsa application I 
do not have to care about pulseaudio at all. And I can drop all 
pulseaudio patches for my application as it targets only alsa.

In user scenario it is similar what you wrote. I'm not using 
pulseaudio at all. I do not have it installed, so why some alsa 
application installing something related with pulseaudio?

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

Yes. I'm using "example" call application from public google 
libjingle tree which implementing voice calls for jabber google 
talk. It is terminal only and use alsa.

Patched code base of this application is used in KDE IM Client 
Kopete for jabber voice calls.

> > > > 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 unloading and loading policy module again (with different 
parameters) is easier.

> > > > > 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/PatchStatu
> s/
> 
> (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".

It is not "any_stream" but for most streams not filtered by 
heuristic. I can rename or add new module parameters, but now I 
will wait for review... so I will not have to edit patch again 
and again.

-- 
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/20141103/bfff2adb/attachment.sig>