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
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
