> It seems that there are some assumptions. I will try to address some > things: > > You can enable/use multiple modifiers per device. > > The modifiers may define extra PCM streams in the standard Value section > - you can use CapturePCM value for the modifier like "Echo Reference". > Modifiers may alter the characteristics of the original UCM device > stream (using command sequences), too. Sorry, not following. The 'modifier' has to be selected by userspace, isn't it? "someone" has to tell UCM that the 'echo reference' is on. And that's precisely the conceptual issue I have. The echo reference in our cases is ALWAYS available when the speaker output is selected. In other words, we are asking userspace to select something that is always present and available. Or put differently, a modifier that's always applicable is not really a modifier, is it? And last, the whole story of the echo reference is that it needs to be opened when the speaker output is opened. How would we model this with the modifier concept? > Modifiers are an extra layer on top of devices. I don't think that we > have any default relation between the modifier PCM device and the > original PCM device (from the UCM device definition). A new value to > describe this (like "ReplacePlaybackPCM 1") may be introduced. Another > issue is when multiple modifiers with this description are active - they > conflict, so it should be described somewhere, too. Perhaps, > "ConflictingModifier" array may be added to API. But those extensions > are not required for the "Echo Reference" modifier. Right, the main issue here is that the PlaybackPCM and Echo reference PCM are joined and need to be handled at the same time. It's not a conflict, they are a bundle or a set of devices that cannot be used independently.
