DM365 audio capture glitching and rate problems

Hi Jon,

Did you ever manage to slove these audio glithces ??
I am having the same issues myself
Any input/help will be highly appriciated
Thanks In Advance

Amir

Sounds a lot like the issue we had / have.  Unfortunately, the problem for us ended up being the processor running out of MIPS.  We had to lower our audio rate to allow the processor to keep up.

I haven't done much more on fixing these - been working on other things. But I did find what I hope is a good lead that looked promising in a quick test (months ago).

commit 1e224f322bf22280957a5f76164d848526ed9b08 "ASoC: DaVinci: pcm, fix underrun by using sram" adds SRAM ping-pong buffers for audio capture/playback which can be defined in board platform data. None of the mainline evm boards set this (as of a few months ago anyway) but you can give it a try. If it works I'm interested in hearing about it - I'll be going back to working on this myself in the next few weeks.

Just in case this is another useful clue, I also have a note to look into a DMA queue and priority default assignment patch that was posted to the DLOS mailing list 19/1/2012 in case that's related.

Hello Povey-san and all,

We are faced by probably the same problem. It happens just using ti-dvsdk_dm368-evm_4_02_00_06/dvsdk-demos_4_02_00_01 "encode" demo application, like "encode -v test.264 -a test.aac -y 5 -r 1920x1080 -u 48000 -w -I 3 -l". When we playbacked the test.aac by PC then we could hear glitching noise. So we think it is the same problem with this.

Do you have some progress about this? Any suggestions are welcomed. We have to solve this problem for mass production application which is developed from the "encode" demo program.... We have to encode both 1920x1080 video and 48000Hz audio simultaneously.

Best regards,

Atsushi Kukutsu

My suggestion is to upgrade your processor to the DM368, which has a faster core frequency.  We tried alot of things only to have to settle with a lower audio sampling rate, which caused other problems.

Hello Ahnen-san,

Thanks for your prompt reply. Unfortunately we are not in the status to upgrade our processor. We will investigate the solution/improvement anyway.

Best regards,

Atsushi Kukutsu

Konnichiwa Povey-san,

Thanks for your prompt reply. We are using "Linux dm368-evm 2.6.32.17-davinci1 #3 PREEMPT". We are checking your commit suggestion. If we get a progress I will report about it.

Arigatou gozaimasu ;->

Best regards,

Atsushi Kukutsu

Konnnichiwa Povey-san,

We struggled to apply your suggested patches and git source code (because our kernel code was very different from your suggested patch status). At last we solved the problem! Captured audio became very clear and seems no data loss compared with original Audio data.

Thank you very much for your suggestion. You saved our lives! ;->

Doumo arigatou gozaimashita.

--------

Atsushi Kukutsu

Kukutsu-san,

Yokatta!

Dou itashimashite.

Kukutsu-san,

I think I am looking at the same problem you had. I am receiving audio samples from a 5158 decoder into the I2S of the DM368. I am using the same kernel level you indicated you were using (2.6.32.17) from the DVSDK.

I get audio but when I load down the DM365 streaming video, the audio clicks and is completely unusable.

I have looked at the patch files that were suggested earlier in this forum. They are definitely for a later version of the kernel. Can you provide any guidance on changes you made to your kernel and any problems you encountered making these changes?

Doumo Arigatou Gozaimashita,

Brian

Hello BrianM-san,

We got patches above and also got kernel source tree form git repository. And we checked main differences of above patches and looked into the concerning kernel code. Then we choose mimimum part of the differences from them and applied them into our kernel code.

We are very busy now and if you wait a few days we will be able to advice more details.

Best regards,

Atsushi Kukutsu

Kukutsu-san,

We are using the TCM capabilities of the DM368 with the H264 encoder. This uses the ram addresses 0x0000 to 0x7ffff for instructions and 0x10000 to 0x17fff for data for the H264 encoder. I have placed the SRAM ping-pong buffer support in my kernel (same level as yours). In the code it looks like the dma_base address in sram_alloc is being set to 0x10000. This is the same address as the TCM data used by the H264 encoder. When I don't encode video, the sound is good. When I encode video, the video is garbled.

Do you know if you are using TCM capability in your environment?  This is set with a flag "useARM926Tcm".

Thanks,

Brian 

Hello BrianM-san,

Sorry for delayed resopnse. I'm not familiar with the H264 encoder settings, so would you tell me how to check whether we are using TCM capabilities?

Best regards,

Atsushi

Kukutsu-san,

TCM (Tightly coupled memory) is something the H.264 encoder can use for faster encoding.  The H.264 encoder can use the SRAM on the DM368 (memory addresses 0x1000 to 0x7FFF for TCM instructions and 0x10000 to 0x17FFF for TCM data). I have been trying to use the SRAM from 0x0 to 0x1000 for the SRAM ping pong buffers for audio. At that location I get a "bumble-bee" sound for the audio. If I move the SRAM buffers to 0x10000, I get good audio unless I try to encode video as well as audio. Today I am going to look at the low memory to see what I am hitting.  Where did you locate you SRAM buffers for audio?

Look in the h264_encoder_dm365_userguide.pdf file for more information.  This is found in the dvsdk in the docs subdirectory in the codecs section under h264enc.

There is variable called enableARM926Tcm that is use to turn on the Tcm capability. The encoder uses TCM by default unless you set the encodingPreset to XDM_USER_DEFINED. You can the control whether you want it or not. it is a member of the IH264VENC_Params structure.  This is passed in to the codec as a VIDENC1_Params with the size member set so that the codec knows that you are passing in a IH264VENC_Params struct.

I hope that helps.

Brian

Kukutsu-san,

Where did you locate your SRAM ping-pong buffers for audio?

Thanks,

Brian

Hello BrianM-san,

We are using the H264 encoder via dvsdk-demos_4_02_00_01/encode program as it is. We just modified it to send video/audio rtp stream instead of saving to the files.

So I think we use TCM because we don't set the encodingPreset to XDM_USER_DEFINED, just default value XDM_DEFAULT.

And for audio ping pong buffers, I don't know about it now because we just applied patches without digging about those code meaning. If you look into the pathes you will be able to know about it.

I'm sorry we are still sooooo busy that I cannot do apt response to you. Soryy for unconvinience.

Best regards,

Atsushi

Hello BrianM-san,

Sorry for my delayed response. We are still sooo busy :-<, so would you check URIs below at first? We stated from the points below.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=a0c8326397262f1817ee6c5212ad6adf43e3df36

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef39eb6f212996ede8da47ef45e6dffff1121ec7

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=52e2c5d38ea6f13a19c29da7ba5183e6fac55400

http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-v3-ARM-davinci-map-default-queue-to-edma-channels-td7203331.html

I hope these URIs would be for your help.

Best regards,

Atsushi

Changing the ASP channel event queue from 0 to 3 did the job.

Thank you Jon!

Hello Atsushi Kukutsu,

I think I have a similar problem.

I found some problems applying the suggested patches. So I want to ask you if you could send me your kernel patches.

Thanks in advance,

Angelo

Gadi,

In which Kernel module(s) did you change the event queue priority? Did you also implement the ping-pong buffers that Jon and Atsushi discussed elsewhere in this post? If so, can you provide details?

Thanks,

-Chuck

I changed the file sound/soc/davinci/davinci-pcm.c in davinci_pcm_dma_request:

link = prtd->asp_channel = edma_alloc_channel(params->channel,
davinci_pcm_dma_irq, substream, EVENTQ_3); /* Gadi: was EVENTQ_0 */

I'm not sure about the ping-pong. I cannot tell by looking at the code now whether I'm using ping-pong buffers or not.

Gadi,

Thanks for your prompt reply and your patch information!

I implemented your change—it helps—but does not completely fix all of the issues with this version (2.6.32.17 kernel) of the DaVinci PCM subsystem. I have observed the following two fundamental issues with the PCM drivers used by the DMAI Sound Module/AAC CODEC interfaces:

 1. when encoding video + audio, Sound_read() cannot supply samples at the proper rate and

 2. encoded AAC exhibits sporadic yet significant "pops and clicks", i.e., "audio glitching".

Without any changes, using clock_gettime(MONOTONIC, timespec &t), I have measured nominal times for Sound_read() in the range of 100 - 300 usec; however, frequently but sporadically, this time can extend to as much as 100,000+ usec—clearly, this behavior can explain both issues 1 and 2 above.

BTW: AAC audio encode cycles are ~15,000 - 25,000 usec at the sampling rate of 32,000 sps—not great, but useable.

After changing "prtd->params->eventq_no" to "EVENTQ_3" in davinci-pcm.c (your fix), these extended Sound_read() times are less frequent and shorter (75,000 - 95,000 usec) but are still present (I assume that the "pops and clicks" are still there but less noticeable).

FYI: by reinitializing the Sound_read() input/output buffers during each AAC encode loop, I achieve similar results as with your fix.

All,

Does anyone know whether or not: a) these issues have been fixed in the following kernel? b) there is a kernel patch? or c) there is a bug report regarding these issues?

I would like to nail this issue once and for all—any help will be much appreciated!

Thanks,

-Chuck

Hi Chuk,

I understand you have a DM365 processor and you wish to encode audio samples above 16 KHz. At this point we figured out that the processor was not strong enough to cope with these demands, so we moved to DM368 with a higher ARM clock and it fixed this problem, so it can encode up to 32 KHz with video without glitching or 44 KHz without the video.

Regards,

Gadi

Gadi,

   I should have mentioned it—our processor is the DM368 running at 432 MHz. The environment wherein I took the measurement described in my previous email is: a RTP/RTCP H.264 1280x720 30 fps video /  AAC 32 ksps audio client/server streaming application running completely on a SD Card (i.e., with no A/V file I/O on the DM368) on a low-latency LAN.

   While our RTP/RTCP streaming application produces very good audio/video results, I would like fix—what I believe to be a "bug or sub-standard implementation"—in the DaVinci PCM subsystem's operation since this behavior will show up in new designs (a faster processor will only mask this apparent bottleneck).

  If you have anymore thoughts, I'd be pleased to hear them and thank you,

-Chuck

Jon,

Our development environment is:

   HW: Spectrum Digital DM36x EVM

   OS: linux-2.6.32.17-psp03.01.01.39

   DVSDK: ti_dvsdk_dm368-evm_4_02_00_06

Early in our application development, during H.264 1280x720p video encoding/RTP streaming with AAC-LC 32 ksps encoding/RTP streaming, we are experiencing the same "audio glitches" and "rate problems" that you describe in your post at the top of this thread.  We fixed these issues (mostly) by periodically reinitializing the I/O buffers used by DMAI Sound_read() / Sound_write() and by setting AACENC.useCache = true in the application .cfg file but now want fix these issues by patching the Linux Kernel—apparently, at the source (please see our reply to this thread below where I describe the time measurements that we made around the calls to Sound_read()).  

As you know, this behavior by the DaVinci PCM sub-system can make make the synchronization of A/V very difficult and completely smooth playback almost impossible.

Above, you cite three commits that relate to these issues:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=52e2c5d38ea6f13a19c29da7ba5183e6fac55400

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=ef39eb6f212996ede8da47ef45e6dffff1121ec7

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=a0c8326397262f1817ee6c5212ad6adf43e3df36

while Kukutsu-san lists one more at:

http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-v3-ARM-davinci-map-default-queue-to-edma-channels-td7203331.html

Should we apply all four of these patches or just the three that you cite in your original post?

Your help with this would be much appreciated!

Thanks,

-Chuck