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
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
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
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
>;
};
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
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>
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
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi igorpadykov
Thank you very much for your kind answer.
Is there any way to shift Rx data except change SDMA script?
Hi gi
you also can do shifting in software (in application).
Best regards
igor
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
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.
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
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.
Hi gi
I am afraid there are no other options.
Best regards
igor