On 11/13/2011 03:42 PM, Colin Guthrie wrote: > Hi, > > I've written up my latest proposal to gather feedback before starting > (hopefully soon now) on the implementation. > http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting Nice! > Comments most welcome. Don't forget to have a quick look at the patch > linked in the introduction before looking at the example code chunks in > the wiki page. > > > I'm particularly interested to get feedback from the embedded folks as > I'm very much focussed on the desktop use cases but obviously would like > a system that would benefit other use cases too or at very least didn't > hinder them! First; as you already know, I very much support an improved routing system and so this is mostly about details. > +typedef struct { > + pa_stream_direction_t direction; > + pa_proplist *proplist; > + union { > + pa_sink *sink; > + pa_source *source; > + } device; > + > + union { > + pa_sink *sink; > + pa_source *source; > + } ignore; > +} pa_route_decision_t; 1) Nitpick: I think it's more common with "typedef struct pa_route_decision" 2) I'm a little confused that you don't send a pointer to the actual sink input, only its proplist. Why? 3) union between sink and source - we don't lack memory here, so might be safer to have two different fields instead of a union. Reduces the risk of unpredictable segfaults in favour of predictable ones. 4) Do we really need the ignore field? It is only used in the unlink phase (right?) and in that case the source/sink should already been in a state that the routing modules can use to know that they should not prefer it. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
