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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux