[pulseaudio-discuss] Potential module: persistent-sink
gmane at colin.guthr.ie
Sun Dec 7 03:24:48 PST 2008
'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.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss