[alsa-devel] Problem with MX27 ASoC audio

Randolph Chung rchung42 at gmail.com
Mon Aug 16 11:27:13 CEST 2010

On Thu, Aug 12, 2010 at 11:01 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Thu, Aug 12, 2010 at 10:59:19PM +0800, Randolph Chung wrote:
>> I will double check tomorrow, but I have another version of the code
>> that checks all the return values and I am quite sure the set_channels
>> didn't fail....
> Actually, if the interval between the time periods doubles in the
> failure case that suggests that the hardware may have decided to start
> running in mono mode...

I investigated this a bit further. Sasha is right that only stereo
channels work. However in the end that is not really relevant to my

The below may be a related issue:

I initiate a recording using arecord from the command line:

arecord -D hw:0,0 -f S16_LE -r 8000 -c 2 -d 5 /dev/null
(this command actually takes 10 seconds to complete)

I check the clock rates on the physical connections from the codec:
MCLK = 13MHz
BCLK = 8kHz
WCLK = 256kHz

This seems to be correct. However, on the MX27 side I only get "half"
the data (i.e. the data arrives at a rate of 128kHz). This is checked
by instrumenting the DMA driver in the progression routine or the FIQ
driver in the timer routine. (Also from checking the time arecord
runs) If I hack my codec to double the datarate to 16kHz then I get
back data that plays back correctly at 8kHz (my earlier test was using
this hack, which I had forgotten about). So this seems to be a problem
on the MX27 side.

I am not sure if there is any special additional setup that might be
needed in my machine driver to match up the codec configuration. It
would seem to me that if the MX27 is the I2S slave, then it should
just clock in data using the external clock signals, so I don't quite
understand how the received data rate can not match what is coming
from the codec. Playback works fine without any hacks.

Any ideas? I do not see any in-tree drivers that use MX27+I2S codecs,
only MX27+AC97, which goes through a different path. Just wondering if
the I2S path works for others in the capture case?


More information about the Alsa-devel mailing list