On Thu, Sep 15, 2016 at 1:33 AM, Charles Keepax
<ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
