Edinburgh Murphy meeting notes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux