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:58:36 +0200 [thread overview]
Message-ID: <5570598C.3020103@metafoo.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1506041000080.15001@lnxricardw1.se.axis.com>
On 06/04/2015 10:06 AM, 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.
>
> Ok, thanks.
>
> Actually, in the case in question, there is no real codec for capture,
> it's a MEMS microphone with an I2S output. So patching the codec (which is
> playback only) driver to simply allow capture actually accomplishes the
> desired result, but that's not a viable solution of course, and is only
> proof-of-hardware.
>
> I can't seem to find a simple driver for a MEMS microphone though,
> although since there is actually nothing really to configure on the device
> itself (it has no configuration port, just an I2S output), perhaps I
> should simply be using a dummy driver (snd-soc-dummy) that basically
> enables capture?
snd-soc-dummy is only meant to be used for links which do not have any CODEC
at all. It is kind of a stop-gap solution until the framework gains the
capability to support such links natively.
Even if your device does not have any configuration registers it will still
have constraints like the supported sample rates, sample-widths, etc. You
should create a driver describing these capabilities. This ensures that the
driver will work when the device is connected to a host side CPU DAI that
supports e.g. sample-rates outside the microphones range. The AK4554 driver
is an example of such a driver.
- Lars
next prev parent reply other threads:[~2015-06-04 13:58 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 [this message]
2015-06-04 11:46 ` Ricard Wanderlof
2015-06-04 13:52 ` Lars-Peter Clausen
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=5570598C.3020103@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox