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

Tue Nov 4 03:42:02 PST 2014

On Tuesday 04 November 2014 10:53:04 Tanu Kaskinen wrote:
> 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.
> 

Extending alsa API means that only new version of voip 
applications can be fixed. Solve problem only partially.

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

I talked with some people who do not use PA and do not like it. 
Basically they told me similar/same arguments about PA. 
Rephrased: "Why do I need to install it and use? Everything 
working fine with alsa and in past I had problem with PA (no 
sound, bad quality, etc.). If everything working fine with alsa 
why should I add hacks for PA which even not working correctly? I 
saw how Lennart broke PA with older/legacy kernels which drivers 
did not supported something which PA use. And PA still does not 
support HW mixer..." If you agree or not, you should respect what 
other people think and if they do not like PA (because it not 
working with their cards or has other problems, also 
philosophical) they will do not accept any PA "hacks" into their 
applications. I just want point to that this is real situation 
and pulseaudio should not force other applications (basically 
those which not target PA at all). There are still lot of 
"haters" of pulseaudio same like of systemd. And in my opinion we 
should respect all people.

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

It makes sense if some feature is part of application itself 
(statically linked or so). But linking alsa application with PA 
libraries is nonsense... Config files (suggested by you) is 
somewhere between those (if alsa application package will not 
depends on PA).

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

For my usage I'm planning to add needed parameter into pulseaudio 
config file on my machine.

It would be better to have persistence of this parameter plus 
runtime configure support. But this is out of scope now. I'm not 
planning to implement this support.

-- 
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/20141104/80b81e9d/attachment.sig>