On Mon, 2013-10-28 at 17:50 +0000, Colin Guthrie wrote: > Hi Guys, > > I made a few notes about this meeting. Feel free to add CC's as you see > appropriate. Also please feel free to correct my version of events just > in case I've put something down incorrectly. > > Tanu, Janos, Jaska: Could you please make the two presentations you had > available somewhere for reference? > > > Janos' Slides: (snip, Murphy discussion sent separately to murphy-dev) > Tanu's Slides: > > Routing Groups are currently (under Tanu's plans a core concept, but > myself and Arun suggested that these may be private to the routing > implementation as these may not be useful to other potential > implementations of routing algorithms - e.g. it seems to be slight > leakage of a specific requirement. > > The question of Zones vs. Roles was raised. I'm not super clear on how > these are merged into the single Routing Group concept. > > So problems Pierre had with some of the Node representations were that > some things are simply not exposed from the DSP. Also some > configurations require arbitrary setup before nodes are implicitly > connected in the DSP. These should still be logically represented in the > PA routing. This might require setting kcontrols or it may require > running an arbitrary program (e.g. to load specific firmware for that > route). Arun suggested that this may be something that should go into UCM. > > There are still some issues related to DSP exposure. An internal Intel > meeting with Pierre will likely happen to discuss this further. > > Generally, there was some degree of concern over the number of new core > concepts needed to support this and some questions were asked about > whether some parts are really internal to the routing algorithm > *implementation* itself, rather than the concept of routing algorithms > as generally supported in PA. We all agree we need a better routing > infrastructure, so the only question is really how many of the concepts > are leaks from the current Murphy-based implementation vs. genuinely > useful in the general case. > > (Side note for the sake of completeness: My own opinions are somewhat > corrupted/biased as I originally had intended to implement very limited > support in PA core to implement future routing systems - originally > based only on a new HOOK. > http://colin.guthr.ie/git/audio/pulseaudio/commit/?h=route&id=61d73564c1c2b0b832f14bfd4f2b77c98febb735 > - this is however an old commit and I did do some work to improve it > later: > http://colin.guthr.ie/git/audio/pulseaudio/commit/?h=route2&id=37b2cefce32d173700e93159b2f7fa255a915f92 > with a few more test commits on top: > http://colin.guthr.ie/git/audio/pulseaudio/log/?h=route2 Sadly, I never > got around to finishing this off, but the idea was to keep the core very > lightweight. That said, I did propose to add a "priority list" concept > to the core > (http://colin.guthr.ie/git/audio/pulseaudio/commit/?h=route2&id=a8014744b470f22a56fe6a30e3d3a3ca4a623b1d) > to implement some relatively simple desktop routing cases, but only > implemented it very, very roughly as a semi-PoC after which I sadly > found myself with out much time to concentrate on things much more :( > http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting/ > It should be noted that this was all very much based on *desktop* use > cases, and certainly left a *lot* to be desired when dealing with > embedded h/w and use cases)
