Linux 3.7 ALSA sound support for iMX233?

[ggilles]

Hi g.glowacki,

I am using the latest patch from Michall on a 3.13.6 kernel:

patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing

I don't have the errors you mention. I was not sure if there was a problem after hours of playing, so I ran an experiment. I launched this command-line last friday:

Code Select Expand

aplay -c 2 -f S16_LE -r 22050 /dev/urandom
And it is still running fine now (2.5 days).

Best

[g.glowacki]

I don't have the errors you mention. I was not sure if there was a problem after hours of playing, so I ran an experiment. I launched this command-line last friday:

Code Select Expand

aplay -c 2 -f S16_LE -r 22050 /dev/urandom
And it is still running fine now (2.5 days).

Best

Hi ggilles,
Thanks for You replay. This error appears when I continuously open and close file, not when infinitely playing. Can You check sth like that:

Code Select Expand


while : ; do aplay -c 2 -f S16_LE -r 22050 <some small random data e.g. /bin/bash> ; done

Thanks a lot:)

GG.

[ggilles]

This has been running for 1.5 hour now:

Code Select Expand

while true; do aplay -c 2 -f S16_LE -r 22050 -d 1 /dev/urandom; done

And it's still playing.

[ggilles]

Still playing fine after 4 hours!

[g.glowacki]

Thanks a lot ggilles and Grawp,
Thanks to Your suggestions and patch it's working now. After going to kernel 3.13.6 it's been working now for 5 days. I still get many underflows, however DAC doesn't hang up, I've no overflows also.
Maybe You have an idea, why the underflow may appear?

--
GG

[scout_3pm]

By general an underflow is when the DAC has requested a data output sample, but hasn't got one.

I'm not sure the principle of work of this AUDIO driver now, but if it is not using DMA (Direct Memory Access) or if it is using DMA, but the DMA ISR (Interrupt Service Routine) has low priority or is not optimized enough it can cause this issue.

Again generally a DMA for DAC is used in a ping-pong buffer configuration, where while one buffer is streamed to the DAC another buffer is prepared with data samples. Other more common simpler configuration is a circular buffer, but that requires a little bit more precise work and with more CPU overhead/interference ;-)

Most likely the CPU/MCU/SoC is doing something else, more important (with higher priority) than processing the DMAforDAC ISR and thus postpone the reaction for the next buffer from the audio app.

I can only assume that the DMA is in circular mode with Half Transfer Complete Interrupt which signals when half of the current buffer is transfered so the driver knows when to update the upper half of the buffer and a Full Transfer Complete Interrupt so the driver knows when the buffer will be read from the beginning so the down half can be updated with new data. And as I said this requires more precise timing to handle and if the priority of the DMA ISR is low or the Task Scheduler is switching many tasks it can delay the procedure described above.

Other case is single shot DMA, where the driver continuously is waiting for Transfer complete interrupt of the DMA and when that occurs issues new buffer of single shot DMA transfer with new buffer, in this case is very realistic to have underflows ! But most cases for audio playing in SoC a circular DMA mode is used. I personally prefer ping-pong which is more sophisticated and handy, but not all SoCs or not all SoC's DMA channels support this mode.

You're not able to hear a distinct hang up of the DAC , because at 22kHz sample rate even if you have delayed action from the ISR the last transfered sample to the DAC's output buffer will remain for the next:

T=1/F=1/(22*10^3) ~ 45uS

until the next new sample arrive, if it is missed (underflowed) again it will remain another 45uS as most DACs have autorefresh function which keeps the last transfered sample alive.

This is quite a lot of time for the MCU and I will make this big assumption that you are missing only a few samples, i.e you are having a constant TONE for only a few hundred uS. Even if you lose for example 22 samples which is almost 1 mS you still have the following 22028 samples in that second and it will be very hard to catch that with your ears ;-) Use oscilloscope and you will see how many samples exactly you are missing by looking for how long the value on the DAC output is not changed (where this time is more than 1*T, i.e at least 2*T = 90us or more).

I really got into details, but hope this will help catch the issue:

1.Low ISR priority.
2.Too many processes for the task scheduler.
3.Small DMA buffer (that i forgot to mention, but is also a possibility).

1 and 3 depend on the driver , 2 depends on the system usage. Most likely it is case 1 or 2.

Here is one test you can do :-) :
Try running aplay with 'nice' and with highest possible priority to see if it is the task scheduler ;-)
Check:
man nice
(it is very simple and useful command to set priority of a process in linux)

Good Luck

ps: I'm also going to use the iMX233-OLinuxino-NANO for an audio related project so I will be following the development of the issue.

[benbiles]

Hi, can anyone confirm if audio has been fixed in 3.x kernel or not?

does this patch work? and how do you use the patch if it does?

Do we have to compile the kernel with the patch? or just patch the installed kernel?

Is there a kernel built with audio IO driver working already? if there is do we have a download link
anywhere?



" Hi g.glowacki,

I am using the latest patch from Michall on a 3.13.6 kernel:
Quote from: Grawp on March 13, 2014, 04:52:09 AM

    patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
    dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing

"

[g.glowacki]

Hi, can anyone confirm if audio has been fixed in 3.x kernel or not?

Yes it works. I have kernel 3.13.x.

does this patch work? and how do you use the patch if it does?

I've patched the kernel and compiled it.

Do we have to compile the kernel with the patch? or just patch the installed kernel?

Yes. You need to patch kernel with previously mentioned patch.

Is there a kernel built with audio IO driver working already? if there is do we have a download link
anywhere?

I don't know.
Regards.

[benbiles]

Hi g.glowacki,

Thanks for reply, is there any chance you could post an image of the patched working kernel you built somewhere?

can you explain where you get kernel 3.13.x. from? I have link too https://github.com/koliqi/imx23-olinuxino which is Latest Stable Kernel 3.7.1

and I have cloned https://github.com/ITserve/imx23-audio

trying to build this kernel now with patch..


Also, when you say working audio can you confirm that audio inputs line in L&R stereo and Mic input pin 34 / alsamixer is working cleanly with no random noise and or crashes & buffer under runs ??

Thanks again,

BEN

[ggilles]

Also, when you say working audio can you confirm that audio inputs line in L&R stereo and Mic input pin 34 / alsamixer is working cleanly with no random noise and or crashes & buffer under runs ??

No.
Audio outputs work fine, but audio inputs (both mic and line) have a periodic noise in my setup. I could not track the origin of the issue.

Best regards,

-- Gilles

[benbiles]

Hi Gilles,

So were you using kernel 3.13.x with these patches?

    patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
    dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing

I am trying to build kernel with https://github.com/ITserve/imx23-audio patch but i'm not sure how to update to 3.13.x kernel

I guess I am waisting my time anyway if audio inputs are broken in both 2.x and 3.x kernels !

Thanks for the update..

[ggilles]

So were you using kernel 3.13.x with these patches?

I am using kernel 3.13.6.

To update to 3.13.6, here is what I did:
1. clone the imx223-audio repository checkout the imx23-audio branch
2. generate a patch relative to the master branch: with something like

Code Select Expand

git format-patch master --stdout > audio.patch
3. clone the stable linux kernel remository, checkout v3.13.6
4. apply the patch of step 2

Code Select Expand

git apply audio.patch
you should probably check that the patch applies cleanly first (with the --check option)

Anyway, if you need audio input this does not work better than the 2.x kernel.

-- gilles

PS: untested instructions!

[benbiles]

Hi ggiles,

could you explain how I do this step?

3. clone the stable linux kernel repository, checkout v3.13.6

do I clone this with git and then add imx223-audio to the kernel folder and build?

https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/v3.13.6

I think I should build this regardless to learn a bit about patching the kernel etc..
I have built custom kernels in x86 linux but never ARM!

[benbiles]

I was trying to build using these instructions but can't find the latest kernel for git..


To expand on this a bit more, the instructions I followed are here:

http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html#getting-the-code

I used the https://github.com/koliqi/imx23-olinuxino repository in accordance with above, but instead of using the kernel source from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git, instead I used https://github.com/ITserve/imx23-audio.

I went through the process of using menuconfig to configure the kernel closely in accordance with the above tutorial. What I did in addition to that was navigate through the sound card options and enabled support for the SOC imx23 audio.

The board now runs with the SD card and I'm able to use networking and so forth, but aplay and linphonec clearly show that no audio devices are present.

[macphyter]

I'm trying to get audio working on an Olinuxino, and the patch/dts file mentioned below are no longer available from google drive.  Is there any other place they might be available?  Thanks.

   -Macphyter

---Edit:
Never mind, I found them.  They're in the OpenWRT source tree here if anyone needs them:

https://dev.openwrt.org/browser/trunk/target/linux/imx23/patches?rev=37622

   -Macphyter

Hi Gilles,

So were you using kernel 3.13.x with these patches?

    patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
    dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing

I am trying to build kernel with https://github.com/ITserve/imx23-audio patch but i'm not sure how to update to 3.13.x kernel

I guess I am waisting my time anyway if audio inputs are broken in both 2.x and 3.x kernels !

Thanks for the update..