On Tue, 2013-11-26 at 13:28 +0100, David Henningsson wrote: > On 11/24/2013 06:58 AM, Tanu Kaskinen wrote: > > A "device prototype" is an object that allows referencing potential > > devices, i.e. sinks and sources that don't exist. > > I think this needs further explanation. > > First; if the sinks and sources don't exist, it seems a bit strange to > represent them as sinks and sources...? Maybe pointers to sink_new_data > and source_new_data would make more sense, conceptually? Not sure. The new data structs contain lots of stuff that is irrelevant outside the context of creating a new sink or source, and is also subject to modification by policy modules - not that it's necessarily a big practical problem, but since we're talking about what makes sense conceptually, I don't think sink/source new data is the answer. I think it would be good to change sinks and sources so that they would exist all the time regardless of the active card profile. In that case the device prototypes wouldn't be needed. Changing the sinks and sources that way would have lots of consequences, however, so device prototypes are the easier way forward. > > A card usually has > > profiles that don't contain all devices that the card can create. The > > card knows about all potential sinks and sources, and it would be > > useful to make this information available also outside the card. > > > > In my case I need it for implementing a "rescue policy" for profile > > switch cases in module-skoa-router. The module shouldn't rescue > > streams that are connected to devices that are not actually going to > > be removed, because this causes glitches in the audio. Therefore, the > > module needs to know before the profile switch happens whether a > > device is going to be removed as a part of the profile switch. > > > > The prototype has pointers to a sink and source. The prototype has > > an implicit direction, and if it's an output device prototype, then > > the source pointer must always be NULL (likewise for the sink pointer > > for input device prototypes). The sink/source pointer is non-NULL > > when a sink/source exists that is represented by the device prototype. > > The suggestion to store this prototypes as something that looks like a > set of one source and one sink looks strange to me. What if you had two > hashmaps, one for sinks and one for sources, is this object at all > needed then? I don't know how exactly you meant those hashmaps to be used. Would they be stored in the card object, and what would they contain? It may look, due to lacking documentation and bad explanation above, that the prototype is a set of one sink and one source. It's never a set of a sink and a source, one prototype corresponds only to a sink or a source, not both. It contains both a sink and a source pointer, because the alternative would be to have a type or direction field and a void pointer. Sink and source pointers are more convenient to use. > Also, who owns the actual device prototype object, is it the card > profile or the source/sink? In my implementation the answer is "neither". I made it so that the card back end implementation owns the object, but that was probably a bad choice. It makes more sense to make pa_card the owner of the prototypes, because the prototype life time should always be the same as the card life time. The card profiles shouldn't own the prototypes, because the same prototype can be part of multiple profiles, and sinks and sources can't own the prototypes, because the prototypes exist also during times when the corresponding sink or source doesn't exist. > Finally, this looks like a very small object and unlikely to become > large any time soon. It does not need its own .c/.h files - it would fit > fine inside e g card.h. Ack. -- Tanu
