On Mon, 2013-10-28 at 21:55 +0200, Tanu Kaskinen wrote: > 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. > > Awesome, thanks for the notes! Any objections to sending this to the > pulseaudio-discuss and murphy-dev lists too? > > > Tanu, Janos, Jaska: Could you please make the two presentations you had > > available somewhere for reference? > > My slides can be found at > http://files.tanuk.dy.fi/tmp/node_based_routing_in_pulseaudio.pdf (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. > > My understanding is that if the router implementation cares about zones, > it will have separate routing groups for each zone (e.g. separate "music > output" group for each zone). > > > 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. > > I got the criticism about routing groups - if there are other concepts > that you find questionable, please let me know.
