I would triple this for the steamOS case, which has an inversion of this problem (a playback device that has a coupled capture device for speaker management). Coupling PCM devices statically in the UCM file avoids a class of side effects that could occur if one tried to implement the same behavior with exec calls in Enable/DisableSequence.
On Mon, Aug 28, 2023 at 11:35 AM Pierre-Louis Bossart < pierre-louis.bossart@linux.intel.com> wrote:
On 8/28/23 12:59, Curtis Malainey wrote:
On Sat, Aug 26, 2023 at 4:28 AM Jaroslav Kysela perex@perex.cz wrote:
On 24. 08. 23 23:33, cujomalainey@chromium.org wrote:
From: Curtis Malainey cujomalainey@chromium.org
Sometimes userspace may want to use a reference channel to cancel echos when using video chat, this value identifies the device which carries that channel.
The UCM modifier should be used for this - see "Echo Reference"
comments in
use-case.h.
Note that this allows additional setup (in Sequences) for this stream.
JaroslavI was under the impression modifiers were state manipulators that acted upon existing devices/pcms and did not designate their own PCM. That is at least how we use them in CRAS.
Are there any examples of how to designate a PCM? I don't see any modifiers at all in ucm-conf repo.
I will second Curtis' request for clarifications.
I naively thought that modifiers would be used to e.g. select a 'Deep Buffer' output for low-power playback, or different capture streams based on the needs of the applications. It's not uncommon for capture applications to request different PCM streams for raw, AEC processed, AEC+NS processed data.
Echo reference is not really something that varies based on any qualifiers. And specifically in the Chrome case we want userspace to open the PCM echo reference device whenever the playback is used. So it's not really a use-case dependent thing but more a way to express a dependency between PCM devices.