[alsa-devel] DAPM: codec to codec link documentation[RFC]

[anish kumar]

On Thu, Sep 15, 2016 at 1:33 AM, Charles Keepax
<ckeepax at opensource.wolfsonmicro.com> wrote:
> On Wed, Sep 14, 2016 at 12:08:56PM -0700, anish kumar wrote:
>> Hello,
>>
>> I had a tough time figuring out how to get codec to codec link to work.
>> So thought of making it easier for other people who wants to use the same.
>>
>> I will appreciate any inputs for below documentation. Excuse my diagrams
>> if it doesn't render on your browser. I am still learning as how to best
>> draw txt diagrams.
>>
>> Mostly the flow of audio is always from CPU to codec so your system
>> will look as below:
>>
>>  ----------               ----------
>> |            |  dai      |            |
>>     CPU  ------->    codec
>> |            |             |            |
>>  ----------               ----------
>>
>> In case your system looks as below:
>>                             ----------
>>                            |            |
>>                             codec-2
>>                            |            |
>>                             ----------
>>                                  |
>>                               dai-2
>>                                  |
>>  ----------               ----------
>> |            |  dai-1    |            |
>>     CPU    ------->  codec-1
>> |            |              |            |
>>  ----------                ----------
>>                                  |
>>                               dai-3
>>                                  |
>>                              ----------
>>                             |            |
>>                              codec-3
>>                             |            |
>>                              ----------
>>
>> Suppose codec-2 is a bluetooth chip and codec-3 is connected to
>> a speaker and you have a below scenario:
>> codec-2 will receive the audio data and the user wants to play that
>> audio through codec-3 without involving the CPU.This
>> aforementioned case is the ideal case when codec to codec
>> connection should be used.
>>
>> Your dai_link should appear as below in your machine
>> file:
>>
>> static const struct snd_soc_pcm_stream dummy_params = {
>>         .formats = SNDRV_PCM_FMTBIT_S24_LE,
>>         .rate_min = 48000,
>>         .rate_max = 48000,
>>         .channels_min = 2,
>>         .channels_max = 2,
>> };
>>
>
> Dummy params is probably not the best name here as this is
> setting the actual params for the link.

I think naming it codec_params would do.
>
>> {
>>     .name = "your_name",
>>     .stream_name = "your_stream_name",
>>     .cpu_dai_name = "snd-soc-dummy-dai",
>>     .codec_name = "codec-2,
>>     .codec_dai_name = "codec-2-dai_name",
>>     .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
>>                     | SND_SOC_DAIFMT_CBM_CFM,
>>     .ignore_suspend = 1,
>>     .params = &dummy_params,
>> },
>> {
>>     .name = "your_name",
>>     .stream_name = "your_stream_name",
>>     .cpu_dai_name = "snd-soc-dummy-dai",
>>     .codec_name = "codec-3,
>>     .codec_dai_name = "codec-3-dai_name",
>>     .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
>>                     | SND_SOC_DAIFMT_CBM_CFM,
>>     .ignore_suspend = 1,
>>     .params = &dummy_params,
>> },
>>
>
> Probably worth having a look at DT options as well, not sure how
> well would be supported for c2c links at the mo but probably
> worth mentioning something about it.

I didn't get you. Do you mean using DT option to specify if
a particular node is c2c?
>
>> Note the "params" callback which lets the dapm know that this
>> dai_link is a codec to codec connection.
>> Also, in above code cpu_dai should be replaced with your actual
>> cpu dai but in case you don't have a actual cpu dai then dummy will
>> do.
>>
>> You can browse the speyside.c for an actual example code in mainline.
>>
>> In dapm core a route is created between cpu_dai playback widget
>> and codec_dai capture widget for playback path and vice-versa is
>> true for capture path. In order for this aforementioned route to get
>> triggered, DAPM needs to find a valid endpoint which could be either
>> a sink or source widget corresponding to playback and capture path
>> respectively.
>>
>> Below is what you can use it to trigger the widgets provided you have
>> stream name ending with "Playback" and "Capture" for cpu and
>> codec dai's.
>>
>> static const struct snd_soc_dapm_widget aif_dapm_widgets[] = {
>>         SND_SOC_DAPM_SPK("dummyspk", NULL),
>>         SND_SOC_DAPM_MIC("dummymic", NULL),
>> };
>>
>> static const struct snd_soc_dapm_route audio_i2s_map[] = {
>>         {"dummyspk", NULL, "Playback"},
>>         {"Capture", NULL, "dummymic"},
>> };
>
> For mainline it would likely be expected you would create a very
> thin codec driver for the speaker amp rather than doing this sort
> of thing, as that at least sets appropriate constraints for the
> device even if it needs no control. For an example of such a
> driver you can see:
>
> sound/soc/codecs/wm8727.c

I will include a note about creating a thin codec driver for speaker
amp instead of doing this.
>
> Thanks,
> Charles