imx6 audio 3.14 kernel bug

[sfinx]

Hello,

Sorry if this is inappropriate place for posting kernel bugs - I've tried to reach Freescale audio maintainer (Li.Xiubo) but his email bouncing messages - please point me to the right place if so.

I'm using the DART-6UL kit with IMX6UL CPU and found three kernel problems with audio :

1. The raw audio device can be opened only at 44100 sampling rate. This means that all other rates must be used through plughw interface which leads to CPU consuming software resampling. This line of code at fsl_sai.c:fsl_sai_set_bclk() prevents other rates :

...

                /* Drop the source that can not be divided into the required rate */

                if (ret != 0 && clk_rate / ret < 1000)

                        continue;

...

It is interesting where is the magic value 1000 from ?

2. If you try to open the raw audio using other than 44100 sample rate (aplay -r 8000 -c 1 -D hw:CARD=wm8731audio,DEV=0 some.wav) you will have the kernel error message and unusable audio until next reboot :

...

[   79.495881] fsl-sai 202c000.sai: failed to derive required Tx rate: 512000

[   79.501506] fsl-sai 202c000.sai: ASoC: 202c000.sai hw params failed: -22

...

As I can see all other subsequent audio openings are made with 48000Hz(?!) sample rate and fail despite correct settings.

3. I've got total system freeze several times with infinite debug console scrolling lines about audio interrupts overrun. I still can't reproduce this but in this state the board do not respond to pings or console commands.

I will be appreciated if somebody can point me to the imx audio kernel developer or fix this issues.

TIA, Rus

[igorpadykov]

Hi Rus

one can try to test with i.MX6UL EVK with official nxp bsp

Board Support Packages (3)

i.MX6UltraLite Evaluation Kit|NXP

Regarding non-nxp boards, like  DART-6UL kit - these are supported by its

vendors. Please look at support policy described on

FSL Community BSP Release Notes 2.1 documentation

The maintainer duties:

Responsible to keep that machine working (that means, booting and with some stability)

Keep kernel, u-boot updated/tested/working.

Keep release notes updated

Keep test cycle updated

Keep the most usual images building and booting

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[sfinx]

Hi,

The buggy library remains buggy in any board. Or you think that missing hardfp libraries and headers magically appears at oficial NXP board when installed from the same imx-codec package ? :smileywink: Just try to install the imx-codec to your famous NXP board, compile the g729 example and post the log here - be practicable.

P.S. Issue counted as resolved. NXP likes to hide and ignore the bugs - which means that Freescale software became at NXP totally unsupported just like Sun Java at Oracle.

[igorpadykov]

even correct "library" will not work on wrongly ported

board image, so recommended to try official nxp releases.

imx-codec sw solution provides universal approach as most i.MX

do not have fpu, if necessary one can look fpu optimized codecs on :

Audio Codecs on ARM ISA (Cortex A5/A7/A9/A15/A8... | ARM Connected Community

[sfinx]

BTW: Then why the heck the --enable-fhw option was added to the imx-codec package ? Seems like people with bad luck who bought the IMX with FPU have to throw out the imx-codec because the packge has the hardfpu install option but it just do not works.

[igorpadykov]

you are right, speech codecs are not hardware accelerated

in imx-codec package. In general, every nxp bsp package has Release Notes document,

please find attached one of them, it describes what is supported and what not.

If smth "hw accelerated", there is special note in its description.

[sfinx]

The Variscite DART-6UL runs all libraries except imx-codec supplied by NXP so if we will use the simple logic it will appear that it is NXP imx-codec that do not works. I think mainly because the support people like you did not try to reproduce the issue ever (at any NXP board) - it is definitely easier to pass the buck out to commercially supported third party libs than to try to support Freescale software. I will not recommend to my customers the NXP - it just do not works and do not have the support.