[alsa-devel] [PATCH] ASoC: davinci-mcasp: Correct rx format unit configuration

Peter Ujfalusi peter.ujfalusi at ti.com
Wed Jan 14 15:17:42 CET 2015


On 01/14/2015 03:24 PM, Pascal Huerst wrote:
> Yes, even this single line.
> 
> - u32 rx_rotate = 0;
> + u32 rx_rotate = (32 - word_length) / 4;
> 
>>> Do you have any Idea, what might cause that behavior?
>>
>> No, I don't. I quickly checked on am335x, am437x and on J6 boards and the
>> command you are using works w/o any issue or distortion in recorded audio.
> 
>> what codec or codecs are you using? I see that you record from hw:0,1 and play
>> it back to hw:0,0
>> Can you check if the recorded sample alone is correct? Just record it to a
>> file and look at it on the PC. I did the same and the recorded sample looks
>> fine on my PC as well.
> 
> if I record into a file, it behaves just the same. Noise if
> rx_rotate == 0, correct otherwise. I guess it is a problem in the input
> codec, then.
> 
> input codec:   AK5386
> output codec:  TAS5086
> 
>> Looking at the patch again, I still think it is a valid fix.
> 
> Yes, I agree, the patch looks right.
> 
> I'll have a look into the ak5386 and see, what impact your change could
> have there.

Can you try S24_LE format as well? I think it should work.

I assume you are running the AK5386 as master which would explain the
symptoms. In this mode you have 64bclk per sample (32 per channel).

I believe this should fix your capture in case of S16_LE:
keep the (in linux-next):
fe0a29e163a5d045c73faab682a8dac71c2f8012 : ASoC: davinci-mcasp: Correct rx
format unit configuration

make sure you have (as in linux-next):
d742b925244ce91f16d380befdca473e4536359b : ASoC: davinci-mcasp: Fix rx format
when more bclk is used on the bus

add the following to your machine driver's hw_params callback:

...
snd_soc_dai_set_clkdiv(cpu_dai, 2, 64);
...

I think the issue with your setup is that McASP expects the you have 32bclk
per sample, but AK5386 generates 64 for you, this will mess up the data you
are receiving since in this case we need to shift the data with 16bits before
we invert it.

-- 
Péter


More information about the Alsa-devel mailing list