From: Lars-Peter Clausen <lars@metafoo.de>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Different codecs for playback and capture?
Date: Thu, 04 Jun 2015 15:52:49 +0200 [thread overview]
Message-ID: <55705831.7060305@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1506041343450.15001@lnxricardw1.se.axis.com>
On 06/04/2015 01:46 PM, Ricard Wanderlof wrote:
>
> On Wed, 3 Jun 2015, Lars-Peter Clausen wrote:
>
>> There has been support for multiple CODECs on the same DAI link for a while
>> now. Have a look at
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=88bd870f02dff5c9445286e185f21873f25a977f.
>>
>> Instead of setting the codec_name/codec_dai_name fields in the dai_link
>> create a snd_soc_link_component array with a entry for each of the CODECs
>> and assign that to the codecs field in the DAI link.
>>
>> I'm not too sure how well it works if one CODEC is playback only and the
>> other is capture only and there might be some issues. But this is the way to
>> go and if there are problems fix them.
>
> It doesn't seem as if snd_soc_dai_link_component is used in any (in-tree)
> driver; a grep in sound/soc just returns soc-core.c . Perhaps some
> out-of-tree driver has been used to test it?
This is the only example I'm aware of:
http://wiki.analog.com/resources/tools-software/linux-drivers/sound/ssm4567#multi_ssm4567_example_configuration
>
> How are the different component codecs accessed when accessing the device?
> Or does this happen automatically? For instance, normally I would register
> one card with the single dai and coec, which would come up as #0, so I
> could access the resulting device with hw:0,0 . But when I have two codecs
> on the same dai_link, what mechanism does ALSA use to differentiate
> between the two? Or is it supposed to happen automatically depending on
> the capabilities of the respective codecs.
It will be exposed as a single card with one capture and one playback PCM.
So it will be the same as if the CODEC side was only a single device
supporting both.
next prev parent reply other threads:[~2015-06-04 13:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 11:06 Different codecs for playback and capture? Ricard Wanderlof
2015-06-03 14:26 ` Lars-Peter Clausen
2015-06-04 8:06 ` Ricard Wanderlof
2015-06-04 13:58 ` Lars-Peter Clausen
2015-06-04 11:46 ` Ricard Wanderlof
2015-06-04 13:52 ` Lars-Peter Clausen [this message]
2015-06-04 14:22 ` Ricard Wanderlof
2015-06-04 14:54 ` Lars-Peter Clausen
2015-06-04 15:20 ` Ricard Wanderlof
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55705831.7060305@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=ricard.wanderlof@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.