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

[Tanu Kaskinen]

On Tue, 2014-11-04 at 12:42 +0100, Pali Rohár wrote:
> On Tuesday 04 November 2014 10:53:04 Tanu Kaskinen wrote:
> > On Mon, 2014-11-03 at 15:43 +0100, Pali Rohár wrote:
> > > 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.

Did you read the last paragraph that you quoted to the end? I already
acknowledged that a different mechanism would be needed to cope with
older versions. If you still think that the proposed solution is somehow
incomplete, well, I tried my best. Do you have a better solution in
mind?

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

Yes, I believe that there are many "haters". It still sounds very
unlikely to me that there would be many alsa application developers who
would reject small PulseAudio specific patches, even if they would
benefit a large portion of their user base. Even if a developer hates
his/her users' technology decisions, my belief is that most developers
still choose to support them if it's not too much trouble. Of course, I
may be wrong in my belief. It's not easy to prove it either way, but for
one data point, I know zero such developers.

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

Ok.

-- 
Tanu