audio 'static/clicks' while video capture/encoding running

btw, when viewing the wav file I see some distortion in the waveform at about 45-55 hz ( nearly the same as the 8k buffer size).  I see it using the 'waveform' view but it is noticeable in the 'frequency' view.

Also, when listening to a clean capture ( no video), I cannot duplicate the static by loading down the CPU ( say running   'dd if=/dev/urandom of=/dev/null bs=65536 count=65536' ).

This post seems related.  Was there any resoloution on Tom Hanson's issue?

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/7674/30493.aspx

our MCBSP captures i2s at 48khz.  Each audio sample is 2 channels,  each channel has 24 bits of significant data in a 32 bit frame. Our clocks are driven by the codec.  Our bit clock is 64 bits/sample  x 48khz  samples/second = 3Mbps.

Here are our MCBSP regs:

~ # /mnt/user/mcbsp
MCBSP.ddr...0x00000000
MCBSP.dxr...0x00000000
MCBSP.spcr..0x02000030
MCBSP.rcr...0x00A101A0
MCBSP.xcr...0x00000000
MCBSP.srgr..0x101E0F01
MCBSP.mcr...0x00000000
MCBSP.pcr...0x00000083
~ #
~ #
~ # cat /mnt/user/mcbsp
echo  MCBSP.ddr...` devmem 0x1d02000 32`
echo  MCBSP.dxr...` devmem 0x1d02004 32`
echo  MCBSP.spcr..` devmem 0x1d02008 32`
echo  MCBSP.rcr...` devmem 0x1d0200c 32`
echo  MCBSP.xcr...` devmem 0x1d02010 32`
echo  MCBSP.srgr..` devmem 0x1d02014 32`
echo  MCBSP.mcr...` devmem 0x1d02018 32`
echo  MCBSP.pcr...` devmem 0x1d02024 32`
~ #

brett.bolen said:

I have a streaming application that has static/clicks in the audio.  my audio input is a 475hz tone, and I'm capture at 48khz ( which is what my cirrus logic decoder is using):  Analog is captured to an i2s @ 48hz, 32bit per sample via MCBSP.  EDMA uses 8k buffers approx 21ms ( TI drivers are mostly unchanged).  

brett.bolen said:

Interestingly, when video capture/encoding is running the audio is clean.  I'm capture with alsa's arecord program.  I can be in the middle of a clean capture, start capture/encoding, and hear the clicks.  Then, if I stop capture, the clicks go away.

brett.bolen said:

What is the interaction between audio and video -- is there a dedicated DMA channel for each?  Dedicated IRQ?  What is shared between the two?

TimHarron said:

Is this something you have been able to reproduce on one of the EVMs? If not, can you copy the arguments you passed into arecord so I can try to reproduce it on the EVM? We do not have the Cirrus decoder so I cannot account for whatever differences there may be between the two codecs, but I can at least try to set up a test base using the EVM hardware so I have a starting point for debug.

I'm using arecord -f dat -t wav -d 10 > /audio_test.wav

  -f dat -> 48khz, S16_LE, 2channel -- you might try S32_LE -- this is our native capture i2s stream.

  -t wav -> wav file

  -d 10 -> 10 seconds.

I am working to get our dm365 dvevm up.  I will let you know how it goes.

Brett

I found this in the release notes for r37.  Could it be related?

Fixed in this release (GA, Build r37)

• Video: DM365 video does not look sharp with 720p
• Audio: DM365 audio becomes noisy when played along with encoded video
• MMC/SD: DM365 MMC/SD1 slot does not work for all MMC/SD cards
• NAND: DM365 nandtest fails
• General
  • Enable INPUT_MOUSEDEV in kernel configuration because most Qt applications need it.
  • Enable FRAMEBUFFER_CONSOLE in kernel configuration so splash screen is visible early in boot process.
  • Fix compilation warnings in MUSB driver.

I am using psp37 ( 3.10.00.19) so I have the fix, and we are having the problem during encode ( not playback).  But it sounds like a very similar problem.

What was the fix for this problem?

I'm able to duplicate this problem with the latest dvsdk release on the DM365 EVM.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

The DM365 DVM has the following audio decoder:

root@dm365-evm:~# arecord -l

**** List of CAPTURE Hardware Devices ****

card 0: EVM [DaVinci EVM], device 0: AIC3X tlv320aic3x-0 []

  Subdevices: 1/1

  Subdevice #0: subdevice #0

root@dm365-evm:~#

The kernel was compiled from the last DVSDK_4 release on 17Aug2010.

root@dm365-evm:~# uname -a

Linux dm365-evm 2.6.32-rc2-davinci1 #7 PREEMPT Mon Sep 13 13:50:30 EDT 2010 armv5tejl unknown

root@dm365-evm:~#

The demo files did not work as distributed.  By trial and error I found the following way to capture & encode video.

In loadmodules.sh, I used the following:

modprobe  cmemk phys_start=0x84000000 phys_end=0x88000000 pools=14x128,14x256,14x1024,12x65536,2x3112704,8x1382400,14x1382400

Also, I used 64M for my linux kernel in bootargs:

root@dm365-evm:~# cat /proc/cmdline
mem=64M console=ttyS0,115200n8 noinitird rw ip=10.8.104.74:10.8.104.66:10.8.104.100:255.255.254.0:::off nfsroot=10.8.104.66:/aux/nfs/arago_fs,nolock video=davincifb:osd0=720x480x16,1350K dm365_imp.oper_mode=0 davinci_capture.dev
root@dm365-evm:~#

Encode using:

root@dm365-evm:~# encode -y 3 -v ab.264 -t 10

while recording PCM audio using:

root@dm365-evm:~# arecord -f dat -t wav -d 60 /bad_pcm_during_encode.wav

The audio file has clicks & distortion.

Audio sample and plots sent to TI.

it looks like the click is caused by the start of a video capture frame.  there are about 1600 audio samples per click ( from the freq spectrum plot),  48k/1600 is about 30 hz which is the video frame encode rate.

could the start of a video capture frame cause a missing REVT event from the McBSP?

I noticed another pattern.  there are normally two distortions every video frame, but once a second there is only one.  could this be an i frame?

What happens only once per iframe, but twice for p frames?

Brett

another data point....

On the dm365 dvevm, I hear the distortion at stereo 32khz, stereo 16khz, and mono 48khz.  At lower sampling rates, the distortion is less.  The clicks are not on both channels at the same time ( ie click are still on both channels,  but not always at the same instant).

And, at 8khz I do not hear it.  The audio input is a 475hz sine wave.

do you hear an echo in this forum?

Brett,

The good news is that I have been able to reproduce this problem in the lab. At this point I am working on getting in touch with the factory folks to see if they can chime in. It definitely sounds like there is a real-time deadline that the software is not meeting so my next step is to work on narrowing down where the issue is. I will keep you informed with whatever progress I make.

This is a frequency plot of a pcm captured wave file ( audio is 475hz pure tone).  The vertical bars are higher frequencies are present, and these present themselves as clicks or static when the audio is played.

It shows distortion every 1600 frames -- could this be dma in to and out of the h264 encoder?

When video encoding stops, then the vertical bars stop.  using dm365 dvevm with 'arecord -f dat -t wav -d 15' and 'encode -y 3 -v ab.264 -t 5'.

Clicks present at 48khz, 32khz, 16khz.  also stereo and mono.

Plots by audacity ( 'spectrum view').

Brett,

We have the same problem on dm368 board. Audio is noisy when we capture & encode video. We think the noise is created by left/right channel swapping problem. You can check this link:

http://processors.wiki.ti.com/index.php?title=McBSP_Channel_Swapping

It looks like there are already some patches ready for GIT kernel but I have not tried them yet. Check this thread:

http://e2e.ti.com/support/embedded/f/354/p/58805/211669.aspx

If you are interested in mono audio only you can probably reduce the noise by using mono mix (connect left & right input channels to both ADC channels).

Semek

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

I looked at moving to the latest kernel, but there is cmemk.ko won't compile ( file_operations changed due to BKL removal, it seems). somebody has to have this working, but I haven't found it yet.  I wonder if anybody has backported this to 2.6.32?  How is it possible that we did not see this problem with the MontaVista kernel -- 2.6.18-pro500?

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Re: dvsdk apps & drivers with newer git kernels -- does not compile.

Any progress from TI on this item?  does it look like using the iram bounce buffers are the solution?  what about cmem port to the then git kernel?

Brett,

One thing I was asked to try on my setup was to make a small change to the davinci-i2s.c file found in the /psp/linux-kernel-source/sound/soc/davinci/ folder. This change was from

[...]
   case SNDRV_PCM_FORMAT_S16_LE:
   dma_params->data_type = 2;
   mcbsp_word_length = DAVINCI_MCBSP_WORD_16;
   break;
[...]

[...]
   case SNDRV_PCM_FORMAT_S16_LE:
   dma_params->data_type = 4;
   mcbsp_word_length = DAVINCI_MCBSP_WORD_32;
   break;
[...]

Unfortnately, I have already made this change on our hardware, because we have a fixed format i2s stream.   We have this modification already and it does not help the problem ( the example plots above were capture with this change).

I can try this change with the eval board, and post the results but I don't think it will fix the problem.

Is DSP's EDMA handled differently between the 2.6.18 dvsdk 2 and 2.6.32-rc2 dvsdk3?  We did see a channel swap ( lost samples) with the old kernel/codecs, but it once every 5 or ten seconds.  With the new kernel/codec we see it happening ~30 times a second ( once every encoded video frame).

I've seen references to the EDMA handled differently in the 2.0 codecs, but the dm365 dvsdk ( even the beta dvsdk) does not come with the new codecs. 

   1.  When will the 2.0 codecs be release in the DM365 DVSDK?  Have you tried this to see if it helps the problem?

   2.  What are the EDMA changes between the 1.10.00.08 and 2.0.x  h264enc codec?

Also I've seen references to a 'switched central resource' which can affect the EDMA priority between the ARM and DSP ( please correct/enlighten me if this is incorrect), but I have not seen how to adjust the settings.

  3.  Can I use the SCR to adjust DDR priority between the ARM and DSP?

  4.  Is DDR memory used differently for the h264 encode between the old and new kernel/codec?

I have verified hat this patch has no effect on the audio capture clicking during encoding problem, using a fresh dvsdk 3.10.00.19.  The kernel is unchanged except for the above patch, and the filesystem is arago.

Using audacity, I can see the clicks which ( again) happen every frame in and out of the encoder.

........ Ctrl-V......

I've seen references to the EDMA handled differently in the 2.0 codecs, but the dm365 dvsdk ( even the beta dvsdk) does not come with the new codecs. 

   1.  When will the 2.0 codecs be release in the DM365 DVSDK?  Have you tried this to see if it helps the problem?

   2.  What are the EDMA changes between the 1.10.00.08 and 2.0.x  h264enc codec?

Also I've seen references to a 'switched central resource' which can affect the EDMA priority between the ARM and DSP ( please correct/enlighten me if this is incorrect), but I have not seen how to adjust the settings.

  3.  Can I use the SCR to adjust DDR priority between the ARM and DSP? How?

  4.  Is DDR memory used differently for the h264 encode between the old and new kernel/codec?

Hi Brett,

Has the problem been figured out?

I have the similar problem.

No.  DVSDK4.0 GA is out with new codecs, though.  No kernel fixes though.

The same problems exist with new codecs as well ( just not as bad).

Any updates on this issue?   The latest 4.02.00.06 dvsdk does not seem to address this issue.  When video encoding, audio capture has clicks & static ( probably due to missing capture data).  This is most notable when the input signal is a frequency sweep , say 100hz to 10khz every 10 seconds).

dma or memory contention?

b

ECHO.. ECho.. echo..  ho..

hi brett.

Dm368+aic31 dvsdk4.20 kernel:2.6.32 has this issue. I use the new H264 codec: h264enc.2.30.00.4.

Have you sovle this issue ? I'm so confused about this.

Any ti team support this? .....................

Anything return from TI ? 

echo.