[alsa-devel] Store codec capabilites in alsa
Hello
Is there a mechanism for the codec driver to register the codec capabilities to the ALSA framework ?
The BE CPU dai driver can then read the capabilities of the codec and talk to the DSP.
Thanks
Bharath
On 26/10/12 03:07, Bharath Ramachandramurthy wrote:
Hello
Is there a mechanism for the codec driver to register the codec capabilities to the ALSA framework ?
The codec DAI driver does register some of it's capabilities with the core.
The BE CPU dai driver can then read the capabilities of the codec and talk to the DSP.
You should be able to do this by looking at the RTD codec->driver pointer to get supported rates, formats and channels.
Regards
Liam
On 10/26/2012 3:45 AM, Liam Girdwood wrote: Hi Liam,
The codec DAI driver does register some of it's capabilities with the core.
The CODEC Bharath and I are working with has hardware providing information back to CPU so post processing modules running on CPU can fine tune things on the CODEC continuously.
So, the information need to exposed to CPU is more than supported rates, format, and channels but very CODEC specific.
I doubt that ASoC has mechanism for vendor's own CODEC driver to advertise CODEC specific information. However, we would like to check ahead of time before coming up with something on our own.
Thanks Patrick
The BE CPU dai driver can then read the capabilities of the codec and talk to the DSP.
You should be able to do this by looking at the RTD codec->driver pointer to get supported rates, formats and channels.
Regards
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Sun, Oct 28, 2012 at 06:13:08PM -0700, Patrick Lai wrote:
I doubt that ASoC has mechanism for vendor's own CODEC driver to advertise CODEC specific information. However, we would like to check ahead of time before coming up with something on our own.
Unless you tell us something about what's being advertised it's very hard to comment; it's often the case that things are just new rather than device specific.
On 10/29/2012 10:07 AM, Mark Brown wrote:
On Sun, Oct 28, 2012 at 06:13:08PM -0700, Patrick Lai wrote:
I doubt that ASoC has mechanism for vendor's own CODEC driver to advertise CODEC specific information. However, we would like to check ahead of time before coming up with something on our own.
Unless you tell us something about what's being advertised it's very hard to comment;
CODEC has filters for noise cancellation purpose. CPU will need to know given CODEC has noise cancellation support. Also, CPU needs to know the CODEC registers to program the filters and which digital audio interface would have noise reference.
Thanks Patrick
it's often the case that things are just new rather
than device specific.
On Mon, Oct 29, 2012 at 08:23:28PM -0700, Patrick Lai wrote:
On 10/29/2012 10:07 AM, Mark Brown wrote:
Unless you tell us something about what's being advertised it's very hard to comment;
CODEC has filters for noise cancellation purpose. CPU will need to know given CODEC has noise cancellation support. Also, CPU needs to know the CODEC registers to program the filters and which digital audio interface would have noise reference.
Why is this all not just normal configuration done from the application layer? Especially the noise reference configuration just looks like totally normal routing configuration.
On 10/30/2012 8:13 AM, Mark Brown wrote:
On Mon, Oct 29, 2012 at 08:23:28PM -0700, Patrick Lai wrote:
On 10/29/2012 10:07 AM, Mark Brown wrote:
Unless you tell us something about what's being advertised it's very hard to comment;
CODEC has filters for noise cancellation purpose. CPU will need to know given CODEC has noise cancellation support. Also, CPU needs to know the CODEC registers to program the filters and which digital audio interface would have noise reference.
Why is this all not just normal configuration done from the application layer? Especially the noise reference configuration just looks like totally normal routing configuration.
Agree that for noise reference can be done through normal routing configuration. However, CPU driver does not normally manage CODEC register. In my case, CPU algorithm module needs to know what CODEC registers to program in order to update the filters. So far, ASoC model has partitioned roles of CPU and CODEC to be managed by CPU driver and CODEC driver. Both drivers talk on common interface to allow easy swap out of CPU hardware or CODEC hardware. In our case, the requirement described so far requires tight coupling of CPU and CODEC. We are looking to maintain clean partition while meeting the requirement through ASoc framework.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Tue, Oct 30, 2012 at 11:18:57AM -0700, Patrick Lai wrote:
configuration. However, CPU driver does not normally manage CODEC register. In my case, CPU algorithm module needs to know what CODEC registers to program in order to update the filters.
Why does the CPU driver want to update the filters in the CODEC? Can't the application do this?
participants (4)
-
Bharath Ramachandramurthy -
Liam Girdwood -
Mark Brown -
Patrick Lai