[pulseaudio-discuss] Potential module: persistent-sink

[Colin Guthrie]

'Twas brillig, and Josh Lehan at 07/12/08 08:14 did gyre and gimble:
> Does this sound like a good model to follow?  This is only an example 
> scenario, of course, and the user will need to be free to configure 
> their priority list in any manner they see fit.

IMO, yes, this makes sense to me. I think a priority list makes sense, 
both for the default case and with specific streams. I'd also introduce 
the abstract concept of a "default" sink - while this does exist just 
now of course, it's not remembered in an abstract case. When a new 
stream plays for the first time, it works out that "default" is actual 
"sinkA" and remembers that it wants to be played on "sinkA" from then 
on. I think an abstract concept of default is needed (this can be done 
via a simple module that just piggy backs on to a real sink and flips 
when the default is changed, but there may be a nicer way to expose this).

This does present some problems tho'.

At present, pulse does not expose (via it's protocol) any sinks that 
have been previously detected but are currently offline. Likewise, it 
does not expose any apps (via it's protocol) that have previously used 
pulse but are not currently playing audio.

In order to implement the property list idea It is important to be able 
to present a GUI that allows listing of both these unexposed entities.

While the functionality is arguably nice, there is also the complexity 
to consider. Presenting the GUI in a very simply way is IMO very 
important. Quite a few users just wont care! This is why the Phonon 
(KDE4) system decided to only allow the priority list approach for 
categories of applications (e.g. VOIP, Music, Video, etc.). Phonon has 
this luxuary as it's a new API and applications usign it *have* to set 
their category. Pulse does not have this luxury as it is very often used 
in an wrapped up form (e.g. via audio APIs where setting the category is 
not part of the API of the library that is exposed to the apps using it, 
or via ALSA plugin which also has the same problem).

So while I agree that a priority list is a good idea, I think that the 
the necessity for protocol changes and careful consideration of the GUI, 
should mean that this needs to be quite carefully thought out.

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/]