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.