[PATCH v3 11/17] ASoC: Intel: avs: Firmware resources management utilities
Cezary Rojewski
cezary.rojewski at intel.com
Wed Mar 9 18:23:56 CET 2022
On 2022-03-08 8:42 PM, Pierre-Louis Bossart wrote:
> On 3/8/22 12:31, Cezary Rojewski wrote:
...
>> 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.
There is a clean split - for all the typical scenarios, topology tied to
given sound card defines the stream patterns completely.
Even when considering "functional" split as you mention in third
paragraph, multiple sound cards are still there. So, as I have described
earlier, to prevent any unwanted behaviour, cached module information in
form of ->mods_info, is being locked with help of a mutex. We do not
duplicate such information per sound card as that would be a waste of
memory. No matter how many libraries are mentioned by the topology files
and loaded throughout the lifetime of a driver, there is always just one
base firmware we sent MODULE_INFO to.
In regard to advanced scenarios and more complex routing, it would be
good to have that conversation as a part of dedicated patchset which is
going to follow this one (sooner or later).
Regards,
Czarek
More information about the Alsa-devel
mailing list