linux-kernel - Re: [PATCH 00/13] Extend AHUB audio support for Tegra210 and later

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f2e9f17-2c88-c72d-008c-07cba947db5e@nvidia.com>
Date:   Wed, 8 Sep 2021 10:26:57 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     <broonie@...nel.org>, <lgirdwood@...il.com>, <robh+dt@...nel.org>,
        <thierry.reding@...il.com>, <jonathanh@...dia.com>,
        <catalin.marinas@....com>, <will@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <kuninori.morimoto.gx@...esas.com>
CC:     <sharadg@...dia.com>, <alsa-devel@...a-project.org>,
        <devicetree@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 00/13] Extend AHUB audio support for Tegra210 and later

Hi All,

On 8/27/2021 3:03 PM, Sameer Pujar wrote:
> Earlier as part of series [0], support for ADMAIF and I/O modules (such
> as I2S, DMIC and DSPK) was added. This series aims at exposing some of
> the AHUB internal modules (listed below), which can be used for audio
> pre or post processing.
>
>    * SFC (Sampling Frequency Converter)
>    * MVC (Master Volume Control)
>    * AMX (Audio Multiplexer)
>    * ADX (Audio Demultiplexer)
>    * Mixer
>
> These modules can be plugged into audio paths and relevant processing
> can be done. The MUX routes are extended to allow add or remove above
> modules in the path via mixer controls. This is similar to how specific
> ADMAIF channels are connected to relevant I/O module instances at the
> moment.

> Some of these modules can alter PCM parameters. Consider example of
> resampler (44.1 -> 48 kHz) in the path.
>
>    aplay(44.1 kHz) -> ADMAIF -> SFC -> (48 kHz) I2S -> (48kHz) Codec
>
> The modules following SFC should be using converted sample rate and DAIs
> need to be configured accordingly. The audio-graph driver provides a
> mechanism to fixup the new parameters which can be specified in DT for a
> given DAI. Then core uses these new values via fixup callback and then
> pass it to respective DAIs hw_param() callback. The "convert-rate",
> described in [1], property can be used when there is rate conversion in
> the audio path. Similarly "convert-channels" can be used when there is
> channel conversion in the path. There is no "convert-xxx" property for
> sample size conversions. It can be added if necessary.

In above example, as we see the modules following SFC should be using 
converted PCM parameters (sample rate in above case). For this I am 
currently relying on DT properties ('convert-xxx') which is supported by 
audio-graph-card. This works fine for a static PCM configuration and may 
be fine to start with. But going ahead a more flexible configuration is 
preferred (without the need of a reboot). This came up during [0], but 
now with the introduction of processing modules in the path it becomes 
more important and would be nice to get this addressed.

Are there any mechanisms in place which can be leveraged to apply PCM 
configurations at runtime?
Or any directions/ideas we want to explore?
Any feedback or pointers will be of great help.


[0] https://lkml.org/lkml/2020/2/24/599


Thanks,
Sameer.