[pulseaudio-discuss] Making phonon/kde work nicely with pulse

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 25/02/09 03:39 did gyre and gimble:
>> As you can see, the idea is to list all the various detected h/w and  
>> allow them to be prioritised accordingly. The categories are shown on  
>> the left hand side, but each once shows the same set of "devices"  
>> (albeit potentially in different orders!)
> 
> I think this is both too simple (i.e. ignore system state, docking
> station, see below) and too complex (the preference list should be
> built automatically and can be built automatically I believe).

That as it may be (I'm not disagreeing) but I'm not in a possition to 
dictate what is wrong about the system, I only want to work within it's 
constraints.

And to be honest, the user feedback I get continually is that user 
*like* being able to order their devices like this. That and the way the 
"default" sink is (was?) handled in PA is the single biggest issue I 
have to support on IRC and on other mailing lists, distro channels etc. 
So there are lessons to be learned with exposing more to users that want 
it too.

>>  3. Find a way to have something at the phonon side control the routing  
>> decisions in PA (e.g. by uploading rules etc)
> 
> There's already an API for this. See pulse/ext-stream-restore.h

Yeah that's why I mentioned my second 3 like that! To be honest I've 
looked at it in the past and am none the wiser!

>> What do you think is needed and what should I work on to get there? Do  
>> you see any major roadblocks?
> 
> Hmm, when we do this: the profile stuff probably needs to kept in mind
> as well: i.e. it might make sense to switch the profile a card in some
> cases by m-s-r. I.e. if a stream is tagged as "phone" call we should
> switch to HSP/HFP mode of a bt headset. If it is tagged as "music" we
> should switch to A2DP mode. This is obviously a pretty static rule,
> but for ALSA devices it might be more dynamic/history based. i.e. for
> "phone" switch to the internl speaker profile of an alsa card, for
> "video" and "music" to the spdif profile, and so on.
> 
> And then there's also the big question what to do about jack sensing
> and docking station support. In both cases the profile of a card might
> need to be switched, and streams might need to connect to a different
> sink.

Yup totally agree. That will certainly be a challenge, but for now I'd 
like to get the integration at least started, even if it lacks profile 
switching support initially. Perhaps there is some kind of half way 
house approach whereby some things can be done now. e.g. having a 
priority list rather than just a default and having some way to remember 
disconnected sinks (and remove old ones that will never return - e.g. an 
old sound card from this cache).

These things will be needed in some capacity, although I guess the 
device priority stuff can be tweaked a bit. I'll try and engage the 
phonon guys a bit and see what beef they have with UI changes.

> I haven't yet gotten my mind all around this.
> 
> If we beef this up, then we should it properly, i.e. somehow bring
> profiles and jack sensing/docking station support into the
> equation... No cluet how that should look like however.
> 
> To formalize this a bit: The decision of selecting the appropriate
> device/profile for a stream should be based on multiple variables:
> 
> - properties of the stream itself
> 
> - system state (docked/undocked)
> 
> - card state (jack sensing)
> 
> - history
> 
> Part of this ruleset needs to be static. Part of it dynamically and
> bound to history.
> 
> Gah, this becomes messy.

Indeed. I think trying to do everything automatically can ultimately 
lead to problems tho'. Sometimes you just need to do a best effort stab 
at it and then rely more on history than anything else, while providing 
a UI to allow people who need full control to change things.

In the end, the OSX priority list is pretty nice and simple and doesn't 
do all this stuff.

While the full control based on all these input params, a simple 
priority list that users know about and know how to tweak is often the 
best solution. If the user cannot understand *why* and automatic 
decision was made, it's almost always better to not make and automatic 
decision!! At least that's my opinion!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]