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

[Lennart Poettering]

On Tue, 24.02.09 21:20, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Hi Lennart,
>
> OK, so attached should be a screenie of the KDE settings window.
>
> 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).

> As is clear it does show some devices that are not currently  
> attached/detected.
>
> So to make this work nicely with pulse, I'd need to be able to:
>  1. Record the sinks seen and know whether they are currently alive or  
> not (e.g. for USB, bluetooth and network sinks).
>  2. Provide a way to prioritise our sinks in a list. If the most  
> preferred sink is not available (and our stream is not specifically  
> playing on a given sink) it should automatically pick the next device  
> with the highest priority.
>  3. Allow this priority list to be different for different  
> roles/categories.
> or
>  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

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

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.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4