* DAPM: codec to codec link documentation[RFC]
@ 2016-09-14 19:08 anish kumar
2016-09-15 8:33 ` Charles Keepax
0 siblings, 1 reply; 4+ messages in thread
From: anish kumar @ 2016-09-14 19:08 UTC (permalink / raw)
To: Linux-ALSA, broonie@kernel.org, Liam Girdwood, Lars-Peter Clausen,
Charles
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,
};
{
.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,
},
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"},
};
Thanks,
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: DAPM: codec to codec link documentation[RFC]
2016-09-14 19:08 DAPM: codec to codec link documentation[RFC] anish kumar
@ 2016-09-15 8:33 ` Charles Keepax
2016-09-26 5:53 ` anish kumar
0 siblings, 1 reply; 4+ messages in thread
From: Charles Keepax @ 2016-09-15 8:33 UTC (permalink / raw)
To: anish kumar
Cc: Linux-ALSA, broonie@kernel.org, Liam Girdwood, Lars-Peter Clausen,
Charles
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.
> {
> .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.
> 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
Thanks,
Charles
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: DAPM: codec to codec link documentation[RFC]
2016-09-15 8:33 ` Charles Keepax
@ 2016-09-26 5:53 ` anish kumar
2016-09-26 8:46 ` Charles Keepax
0 siblings, 1 reply; 4+ messages in thread
From: anish kumar @ 2016-09-26 5:53 UTC (permalink / raw)
To: Charles Keepax
Cc: Linux-ALSA, broonie@kernel.org, Liam Girdwood, Lars-Peter Clausen,
Charles
On Thu, Sep 15, 2016 at 1:33 AM, Charles Keepax
<ckeepax@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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: DAPM: codec to codec link documentation[RFC]
2016-09-26 5:53 ` anish kumar
@ 2016-09-26 8:46 ` Charles Keepax
0 siblings, 0 replies; 4+ messages in thread
From: Charles Keepax @ 2016-09-26 8:46 UTC (permalink / raw)
To: anish kumar
Cc: Linux-ALSA, broonie@kernel.org, Liam Girdwood, Lars-Peter Clausen,
Charles
On Sun, Sep 25, 2016 at 10:53:25PM -0700, anish kumar wrote:
> On Thu, Sep 15, 2016 at 1:33 AM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > On Wed, Sep 14, 2016 at 12:08:56PM -0700, anish kumar wrote:
> >> {
> >> .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?
I just mean that most machine drivers these days specify at least
part of the DAI link configuration through device tree. I don't
know off the top of my head what support is currently provided for
codec to codec links in DT, my suspicion is none. So it might be
worth at least noting that.
Thanks,
Charles
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-09-26 8:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-14 19:08 DAPM: codec to codec link documentation[RFC] anish kumar
2016-09-15 8:33 ` Charles Keepax
2016-09-26 5:53 ` anish kumar
2016-09-26 8:46 ` Charles Keepax
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).