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