On 29. 08. 23 18:30, Pierre-Louis Bossart wrote:
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.
The function of modifier is selected by it's name, so an app should know, how to handle the "Echo Reference". And this use is optional.
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?
Yes, in this special case, only joined PCM will be provided. But do not forget, that we have command sequences for modifiers, if we need to initialize something else like related controls for this stream in future. It's just more universal than to hardcode this to key/value in the UCM device definition.
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?
The modifiers are allowed to be activated only for the active devices. We can refine the use of the "Echo Reference" for applications and define that the playback PCM should be opened at first. If we need to alter this default behaviour in future, we may put a hint to configuration values.
Jaroslav