On 3/8/22 12:31, Cezary Rojewski wrote:
On 2022-03-08 7:26 PM, Ranjani Sridharan wrote:
On Tue, 2022-03-08 at 19:07 +0100, Cezary Rojewski wrote:
Keeping in mind that this driver is meant for older platforms, how
likely are you to support multiple sound cards with those
topologies?
Not sure what's the question here. Age of the platform has nothing to
do
with the subject. There is not a single DSP-capable platform that
Intel
has shipped that would not contain more one audio device onboard. At
least I'm not aware of any.
My question was related to your comment about multiple sound cards.
What I asked was do you plan to support multiple topologies with
modules spread across then with multiple sound component drivers with
the AVS driver and firmware? Does this mean you will need multiple
topology files and machine driver? And what is the rationale for this?
If not, there's no need for the mutex.
Yes, avs-driver embraces granular sound card approach as opposed to
super card approach. There is one topology file per sound card.
That subject is not part of this patchset though.
You would still need to clarify how the same set of modules might be
accessed or configured when different cards are created, or if there is
a 'clean' split with a 1:1 mapping between module and cards.
The more I think of this the less practical this 'granular' approach
looks, e.g. if you want to route the same stream to different interfaces
handled by different cards. An example is playing a notification on
local speakers controlled by HDaudio and a Bluetooth headset using I2S.
This could be really fun to represent even basic volume control to
users: controls are card-specific and some parts may be handled in
different cards and thus different UCM files.
I really think the best split of a DSP topology is between orthogonal
parts. When muxers/demux are used, or multi-input modules such as AEC,
the routing complexity outweighs the benefits of a simpler card design.
