Post Go back to editing

Problem encoding analogue audio with ADAV801

Hi,

I am attempting to add ADAV801 codec support to my 2.6.35 kernel to be
used with an ARM processor. I can see that there is a mainlined
adav80x.c driver that appears at kernel version 3.1, I have had a
quick look at back-porting the driver but this looks as though it
could get quite messy.

However, I did come across an older ADAV801 driver which looks a lot
simpler, but I cannot find it in previous mainlined kernel versions,
http://www.spinics.net/lists/alsa-devel/msg36465.html, so I thought I
would use this as a basis for my own driver.

From what I understand from the datasheet and the way the older driver
has configured the registers on the ADAV801 I should be able to see
some data on the record outputs, however this is not the case. Could
anyone confirm whether or not this driver dated August 2010 is OK to
use? Or perhaps some advice on areas to look at that may be preventing
the CODEC from manipulating and outputting the digital conversion.

Best regards

  • Hi,

    The old driver should probably work, but I'd to you to try to backport the new driver, since it is much more complete and well tested. It shouldn't be to hard, the main thing you have to take care of is the 'Multi-Component' ASoC API change. But you can probably copy the old API directly from the old driver.

    How does your ASoC board file configure the codec and how do you test whether record words?

    - Lars

  • Hi,

    Declaring the CODEC as a SPI device will only register the CODEC to the ASoC framework. But the ASoC framework will not instanciate the CODEC as long there is no ASoC board driver using the CODEC. You'll also need at least I2S and PCM drivers since ASoC will only instanciate the CODEC once all components required to form the sound card are present.

  • Hi,

    Well, as far as I can see by the default the I2S interface of the codec is in slave mode. It can be configured to master mode in adav80x_set_dai_fmt which is ususually called by the a ASoC board code. See the patch following the one you posted the link to, to see an example of such a board driver (http://www.spinics.net/lists/alsa-devel/msg36466.html).

  • Hi,

    I did try compiling the new driver but the amount of errors scared me off, I will go back to it if you think that would be the best course of action.

    ASoC board file? Do you mean how do I register the codec with the platform? If so I have simply declared the codec as a spi platform device, specifying the bus number, chip-select etc. I take it I am missing something here?

    I will be testing the codec for activity on the record output using a logic analyser, once I see data and clocks on the scope I will look at the how the SoC handles the I2S data. In the meantime I am concentrarting on getting the device doing somehting.

    Regards

    Wayne

  • Correct me if I am wrong, at a lower level, I should be able to perform SPI writes on the CODEC in a an effort to configure it to output encoded analogue data. Wouldn't what you are describing only become necessary once I connect up the CODEC digital output to the SoC? at the moment I have the CODEC output hooked up to a scope to verify that the device works.

    Much appreciated as always

    Wayne

  • I think I am starting to understand what you are saying. I guess what it is I don't underdtand is the relationship between ASoC and the driver. I can see that there are areas of the driver that are not being executed. For example the function that is tied to the .hw_params in the structure snd_soc_ops does not get called therefore I am obviously missing some sort driver intialisation.

    Thanks again

  • Hi,

    In ASoC a sound card is composed of multiple components. One is the CODEC the other are the I2S and PCM host drivers. A ASoC board driver binds these components together and properly configures them, so they can talk to each other (You'd normally configure your I2S host and the CODEC for the same on-wire format). This is done using snd_soc_dai_set_fmt, snd_soc_dai_set_sysclk, etc. functions from your ASoC board driver.

    The hw_params callback is called once an application wants to start playback or recording.

    Also note that ASoC has a feature called DAPM(Dynamic power management) which will power-down the CODEC parts which are not in use.

    So unless you have a ASoC board driver which properly configures the CODEC and a userspace application which records something from the ALSA soundcard you are unlikely to see the CODEC transmitting any signals.

    In your case I'd recommend that you write a dummy I2S and PCM driver for your platform which don't do anything right now and use the ASoC board driver from the link in the previous post and adjust it to your needs.

  • Hi,

    I always use aplay/arecord for testing. e.g. `aplay /dev/urandom` should output some noise.

    Make sure that you've enabled the proper controls and setup the volumes in alsamixer.

    - Lars

  • Hi,

    Just an update for you I think I have everything loaded, I created a ASoC board driver and implemented the PCM and I2S functionality for my platform. I also have the codec loading up when the board driver is inserted. Therefore, on paper everything looks ok.

    I guess my next question is what would you recommend to use to test the playback/recording functionality, I have a scope on the outputs of the codec just need some control.

    Thanks

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin