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

[Tanu Kaskinen]

On Mon, 2014-11-03 at 15:43 +0100, Pali Rohár wrote:
> 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:
> > > > 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.

Well, it would still be nice to have the option to fix it once instead
of doing the profile switch every time when using the application.

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

The binary name is the best identifier that I'm aware of when the
application doesn't provide media.role itself. I'm not pretending that
it's perfect - it's not - but it's good enough in many cases.

By the way, I've changed my mind about the ideal solution for passing
media.role from alsa applications: it shouldn't be too hard add some API
to alsa-lib that would allow applications to describe the purpose of
their streams. The configuration file based solution that I proposed
earlier would still be useful for dealing with applications that don't
use that new API, though.

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

Really, do you know such developers? If the developer writes the
application for him/herself only, and doesn't want any features in it
that he/she doesn't need, then that's understandable. But if the target
audience includes people who run PulseAudio (which I believe is the case
for most alsa applications), then I don't understand such behaviour.

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

If the majority of your users use your application on top of PulseAudio,
it's pretty strange to not care about PulseAudio at all, if caring means
that your users would be more pleased with your application.

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

Because it's useful for some users of the application. I'm pretty sure
all applications that you use have some feature that you don't
personally need.

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

Thanks, that's an interesting example.

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

Maybe. You haven't described the use case in detail. Would you need
persistence for the parameter (i.e. would module-device-manager have to
remember the previous state after reboot)?

Reloading the module may also cause bugs if the module maintains any
internal state that it can't recover at module load time.

-- 
Tanu