SSI-AC97 with wm9713 makes double size record file

[ghshin]

I'm using a iMX6q processor and the SSI for interfacing a WM9713 codec on ac97-slave mode.
Playback works fine.
Record operation makes double size record file and It takes double seconds to play.
I guess this case following under should make around 1.8MB size file but the recorded file is almost double size.
48000bpsx2chx16bitsx10sec /8 = 1,920,000 bytes
I checked audio ADC sample rate register of wm9713
also checked BitClock and FrameSync. I get 12,288 MHz and 48Khz when it records.

Does anyone know what make this situation?
thanks in advance.

this is debugging message
-----------------------------------------------------------------------
sabresd_6dq:/data/local/tmp # tinypcminfo -d /dev/snd/pcmC0D0c
Info for card 0, device 0:
[soc_pcm_open]

PCM out:
Access: 0x000009
Format[0]: 0x000004
Format[1]: 00000000
Format Name: S16_LE
Subformat: 0x000001
ASoC: min ch 1 max ch 2
Rate: min=8000Hz max=48000Hz
Channels: min=1 max=2
Sample bits: min=16 max=16
Period size: min=32 max=16384
Period count: min=2 max=255

PCM in:
Access: 0x000009
Format[0]: 0x000004
Format[1]: 00000000
Format Name: S16_LE
Subformat: 0x000001
Rate: min=48000Hz max=48000Hz
Channels: min=1 max=2
Sample bits: min=16 max=16
Period size: min=32 max=16384
Period count: min=2 max=255

sabresd_6dq:/data/local/tmp # tinycap test.wav -r 48000 -c 2 -b 16 -T 10
[soc_pcm_open]
ASoC: wm9713-hifi <-> 2028000.ssi info:
ASoC: rate mask 0x80
ASoC: min ch 1 max ch 2
ASoC: min rate 48000 max rate 48000
[soc_pcm_hw_params]
[soc_pcm_hw_params]codec_dai, rate:48000, ch:2, bit:16
[fsl_ssi_hw_params] ch:2, rate:48000
[soc_pcm_hw_params]cpu_dai, rate:48000, ch:2, bit:16
[ac97_hifi_prepare] ADC rate:48000
Captured 962560 frames

sabresd_6dq:/data/local/tmp # time tinyplay test.wav
[soc_pcm_open]
ASoC: wm9713-hifi <-> 2028000.ssi info:
ASoC: rate mask 0xd6
ASoC: min ch 1 max ch 2
ASoC: min rate 8000 max rate 48000
[soc_pcm_open]
ASoC: wm9713-hifi <-> 2028000.ssi info:
ASoC: rate mask 0xd6
ASoC: min ch 1 max ch 2
ASoC: min rate 8000 max rate 48000
[soc_pcm_hw_params]
[soc_pcm_hw_params]codec_dai, rate:48000, ch:2, bit:16
[fsl_ssi_hw_params] ch:2, rate:48000
[soc_pcm_hw_params]cpu_dai, rate:48000, ch:2, bit:16
[ac97_hifi_prepare] ADC rate:48000
Playing sample: 2 ch, 48000 hz, 16 bit, 4096 buf
play buff count:235, total frm:962560
0m20.04s real 0m00.02s user 0m00.11s system

sabresd_6dq:/data/local/tmp # ls -al
total 3772
drwxrwx--x 2 shell shell 4096 1970-01-01 00:05 .
drwxr-x--x 3 root root 4096 1970-01-01 00:00 ..
-rw------- 1 root root 3850284 1970-01-01 00:28 test.wav

[matej_kupljen]

Hi all,

I finally managed to get WM9712 codec working.

At the end I didn't need to enable FIQ (although the comment in sound/soc/fsl/fsl_ssi.c strongly suggest that we need to use it) but I was able to use DMA. The BUG was in my kernel version in SDMA driver, which did not report that it can do 1,2 and 4 byte transfers, but only reported that it can do 4 byte transfers. And that is why I was getting "No matching formats" error when trying to playback something.

At the moment I use generic AC97 codec driver, but I was also able to use also wm9712 specific driver by hardcoding it into the driver, but both behaves the same.

I can playback WAV file normally, everything works as expected, but when I try to capture the file from LINEIN, the recording is "too slow". Meaning, when I playback it, it sounds like it was played in slow motion. If I transfer this file to the PC and play it back with 1.5x speed, it is O.K.

I checked the register settings trough  /proc/asound/ac97audio/codec97#0/ac97#0-0+regs and all the sample rates are set to 48kHz which is what I want. Still, the recording is incorrect.

I tried applying patch suggested by igorpadykov, but if I apply it, I again get an error about "No matching formats". I don't believe this patch has something to do with my problem.

Any ideas what I could try?

Any other hints/suggestions?

Thanks and BR,
Matej

[matej_kupljen]

Hi gi hwa shin,

I am also trying to use AC97 codec with iMX6 SoC. In my case this is WM9712 codec.
I modified DTS and it seems to properly detect the codec and I can also see that alsamixer shows the correct codec.

[ 3.171661] fsl-asoc-card sound: ac97-hifi <-> 202c000.ssi mapping ok

[ 3.681986] ALSA device list:
[ 3.681990] #0: ac97-audio

However, when I try to playback or record the sound (even speaker-test fails) I only get this error:

# speaker-test

speaker-test 1.1.4

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise

[ 41.628282] ASoC: ac97-hifi <-> 202c000.ssi No matching formats

Would be possible to share your DTS definition, just to check what I might be doing wrong?

Thanks and BR,

Matej

[ghshin]

Hi Matej

I hope this will help you.^^

audio port register should be changed depends on your board.

&ssi1 {
pinctrl-names = "ac97-running", "ac97-reset", "ac97-warm-reset";
pinctrl-0 = <&pinctrl_ac97_running>;
pinctrl-1 = <&pinctrl_ac97_reset>;
pinctrl-2 = <&pinctrl_ac97_warm_reset>;
/* sync, sdata, reset */
ac97-gpios = <&gpio5 16 0 &gpio5 15 0 &gpio2 7 0>;
ac97-reset-time = <1000>;
fsl,mode = "ac97-slave";
status = "okay";
};

pinctrl_ac97_running: ac97running {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT19__AUD4_RXC 0x130b0
MX6QDL_PAD_DISP0_DAT20__AUD4_TXC 0x130b0 /* BCLK */
MX6QDL_PAD_DISP0_DAT21__AUD4_TXD 0x130b0
MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS 0x130b0
MX6QDL_PAD_DISP0_DAT23__AUD4_RXD 0x130b0
MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x1b0b0
>;
};

pinctrl_ac97_warm_reset: ac97warmreset {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0 /* TXFS */
>;
};

pinctrl_ac97_reset: ac97reset {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x1b0b0 /* TXD */
MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x1b0b0 /* TXFS */
MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x1b0b0
>;
};

[matej_kupljen]

Hi gi hwa shin,

thank you for the reply. Looking at your DTS, it seems that I do not have any mistakes. Of course I have changed the SSI ports that I use, but other than that it seems O.K. This is how my DTS entries looks, all of them for audio.

sound {
   compatible = "fsl,imx-audio-ac97";
   model = "fsl,imx6q-ac97";
   audio-cpu = <&ssi2>;
   audio-codec = <&codec>;
   audio-routing =
      "AC97 Playback", "Line Out Jack",
      "Line In Jack", "AC97 Capture";
   mux-int-port = <2>;
   mux-ext-port = <5>;

}

&iomuxc {
   imx6q-phytec-pcaaxl3 {
      pinctrl_ac97_running: ac97running {
         fsl,pins = <
            MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x1b0b0
            MX6QDL_PAD_DISP0_DAT17__AUD5_TXD 0x1b0b0
            MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x1b0b0
            MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x1b0b0
            MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
         >;
      };

      pinctrl_ac97_warm_reset: ac97warmreset {
         fsl,pins = <
            MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x1b0b0
            MX6QDL_PAD_DISP0_DAT17__AUD5_TXD 0x1b0b0
            MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
            MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x1b0b0
            MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
         >;
      };

      pinctrl_ac97_reset: ac97reset {
         fsl,pins = <
            MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x1b0b0
            MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x1b0b0
            MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x1b0b0
            MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x1b0b0
            MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
         >;
      };
   };
};

&audmux {
   status = "okay";

   ssi2 {
      fsl,audmux-port = <1>;
      fsl,port-config = <
         (IMX_AUDMUX_V2_PTCR_TFSDIR |
         IMX_AUDMUX_V2_PTCR_TFSEL(4) |
         IMX_AUDMUX_V2_PTCR_TCLKDIR |
         IMX_AUDMUX_V2_PTCR_TCSEL(4))
         IMX_AUDMUX_V2_PDCR_RXDSEL(4)
      >;
   };

pins5 {
   fsl,audmux-port = <4>;
   fsl,port-config = <
      0x00000000
      IMX_AUDMUX_V2_PDCR_RXDSEL(1)
   >;
   };
};

&ssi2 {
   status = "okay";
   cell-index = <1>;
   fsl,mode = "ac97-slave";
   pinctrl-names = "ac97-running", "ac97-reset", "ac97-warm-reset";
   pinctrl-0 = <&pinctrl_ac97_running>;
   pinctrl-1 = <&pinctrl_ac97_reset>;
   pinctrl-2 = <&pinctrl_ac97_warm_reset>;
   ac97-gpios = <&gpio5 12 0 &gpio5 11 0 &gpio7 12 0>;
};

Spot any errors?

As I said, it detect my AC97 codec, and it is recognized correctly.

It is shown as:

[ 4.254535] fsl-asoc-card sound: ac97-hifi <-> 202c000.ssi mapping ok

[ 6.801499] ALSA device list:
   [ 6.801502] #0: ac97-audio

Is you card detected as ac97-audio?

Only when I do a playback (or record) I get a "strange" error about formats:

[ 21.461652] ASoC: ac97-hifi <-> 202c000.ssi No matching formats

[ghshin]

Hi Matej,

Is you card detected as ac97-audio?

>> Yes

I guess there might be some problem on codec dai format that you can check

it in wm9712 driver.

2019년 8월 28일 (수) 오전 2:36, matej.kupljen@gmail.com <admin@community.nxp.com>님이

작성:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: SSI-AC97 with wm9713 makes double size record file

reply from Matej Kupljen

<https://community.nxp.com/people/matej.kupljen@gmail.com?et=watches.email.thread>

in i.MX Processors - View the full discussion

<https://community.nxp.com/message/1197445?commentID=1197445&et=watches.email.thread#comment-1197445>

[igorpadykov]

Hi gi

in general one can consider erratum ERR003778 SSI: In AC97, 16-bit mode, received data

is shifted by 4-bit locations.

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf 

also for verifying ssi settings may be useful to test with baremetal sdk, its zip can be found on link

SMP Enable in IMX6 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ghshin]

Hi igorpadykov

Thank you very much for your kind answer.

Is there any way to shift Rx data except change SDMA script?

[igorpadykov]

Hi gi

you also can do shifting in software (in application).

Best regards
igor

[jhkim3]

Hi igorpadykov

Could tell me that how to shift data in application?

When I receive data at linux user land, It is already data shifted right by 4 bits.
How do I recover it?

[igorpadykov]

as described in ERR003778 i.MX6DQ Errata document:

"The SDMA script should be updated accordingly to perform the shift..

Workarounds:
The data should be shifted to the right location by the SDMA script or by the software in case of
direct access to the register."

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf 

New sdma script can be created only using NXP Professional Services :
http://www.nxp.com/support/nxp-professional-services:PROFESSIONAL-SERVICE

Best regards
igor

[eric_kang]

Dear Igor,

The ERR003778 is Error, not the requirement.

So I think the SDMA script to shift the location have to be provided by NXP.

Please share that.

Best Regards,

Eric.

[igorpadykov]

Hi Eric

please try with latest NXP Linux L4.14.78_1.0.0 release

https://source.codeaurora.org/external/imx/linux-imx/tree/?h=imx_4.14.78_1.0.0_ga

In particular check AC97 comments in driver linux/sound/soc/fsl/imx-ssi.c :

imx-ssi.c\fsl\soc\sound - linux-imx - i.MX Linux kernel 

some third party board VT1613 AC97 codec   http://download.udoo.org/files/schematics/UDOO_REV_D_schematics.pdf 

dts example

imx6qdl-udoo.dtsi\dts\boot\arm\arch - linux-imx - i.MX Linux kernel 

If this will not help please proceed with NXP Professional Services|NXP 

to develop custom driver or workarounds.

Best regards
igor

[ghshin]

Hi igor

I'm sorry to bother you.

controlling buffer in application isn't  proper for this project.

can i fix it in device driver?

I checked EDMA and SSI registers in datasheet IMX6DQRM but I couldn't find the register to shift it.

thanks.

[igorpadykov]

Hi gi

I am afraid there are no other options.

Best regards
igor