Audio capture on SATA HDD problem - OMAP L138

Add the following options to "arecord", to be sure that you are really using the hardware:

--disable-format --disable-resample --disable-softvol

Without these switches, arecord may "fake" things by using software resampling and similar conversions to get the output you asked.

While recording, watch the CPU usage. The problem isn't likely to be the harddisk.

Another thing to try is to record directly to the disk without filesystem, e.g. by using "/dev/sda" as destination.

Thanks Mike for the suggestion regarding the behaviour of  "arecord" ;o)

I tried to capture with the below command at 96kHz in 32bits little endian format without much success. Samples are always missing into the wave file. The CPU usage is only 12% in average:

arecord -c 2 -r 96000 -d 600 -f S32_LE /mnt/sata/test .wav --disable-format --disable-resample --disable-softvol

Mike, I don't want you to spend too much time but could you please give me the command to capture audio without the filesystem?

Thanks in advance for your precious help!

You could try capturing to RAM (while will obviously eat your ram, so make it short) by writing to /tmp/, or to /dev/null if you just want to look at error messages.

To capture to raw disk, you could run

arecord -c 2 -r 96000 -d 600 -f S32_LE  --disable-format --disable-resample --disable-softvol > /dev/sda

provided that /dev/sda is your sata disk (type "mount" to get this information). Note that this will destroy all data on that disk.

For this to work, the disk must NOT be mounted, so remove it from fstab or udev/mdev rules, or manually unmount it with "unmount /mnt/sata".

For analysis you can put the disk in a PC and copy the data into a file using "dd if=/dev/sdX of=~/myfile.wav bs=1024 count=10240" to get the first 10 MB.

I tried both capturing to RAM and to the SATA disk as a raw disk without, unfortunately, any improvements. All above experiments where done on two separate LogicPD Experimenter Kit with two OMAP L138 SOM from different revision with one SSD drive for one (laboratory power supply) and a classic SATA drive for the other (ATX power supply).

At the early beggining, I supposed this issue was coming from the SATA disk or the embed controller but as I can see, with your help, it comes from elsewhere but I have no more idea! Do you know if anyone report similar issue capturing audio with OMAP L138?

We're using the OMAP-L138 to capture from up to 8 codecs simultaneously resulting in a 16-channel, 32-bit, 51kHz signal. So 2-channel 96kHz should not be a problem.

We have seen issues with the DSP, just loading the codec-engine will cause corruption of the audio data (but no overruns) even though the DSP is not using the audio part at all.

I have also seen buffer overruns being reported when the clocks weren't set right, for example in our case requesting 48kHz while the clocks can only deliver 51kHz will cause overruns to be reported. So check and double check the things that are configured for the McASP and codecs, don't trust that the drivers are correct. Adding lots of "printk" statements in the kernel drivers will help.

I'm also quite a bit confusing regarding capturing only 2 channels even at 96kHz!

Yesterday, I spent a few hours to adapt the "audio soc example" from the SDK to capture (and also simultaneouly looback) 2 channels from the TLV320AIC3106 using EDMA with ping/pong buffers. The loopback give me entire satisfaction. But as soon as I do the samples buffers transfer from the DSP to the ARM to save data to a file in RAM or onto the SATA drive, I get into trouble. Moreover, regarding your posts on the McASP clocks, I also simulate a data acquisition with a timer on the DSP which generates a 1kHz sinewave at 96kHz (no McASP nor EDMA, nothing excepts a timer). I was again surprise to see missing samples into the file!

I think there's something wrong with Linux (and/or the LogicPD SOM) which is corrupting the buffers, using the memory space used by the driver and/or a high priority interrupt during the write to file from the samples!!!

As you recommand, I will check and double check thing into drivers. Also, I plan to disable all unneeded drivers into the kernel to see if there's improvements and at the same time use another filesystem like angstrom with only the strict minimum files to be sure nothing is running at Linux start-up etc... Maybe, further, compile a more recent stable kernel to see what happens.

Do you use the same LogicPD OMAP L138 as me? If not, I will buy a new evaluation board probably LCDK from Ti to see if something similar happens. What evaluation board did you use for the development of your 16 channel application?

Many thanks again for sharing your knowledge!

If you're using the DSP codec-engine, you may be bitten by the same problem as we're experiencing with that module:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/231409/813458.aspx

Something in the codec engine messes with audio capture. It does not happen when using plain dsplink.

We're doing the audio capture on the ARM side, via Linux ALSA drivers. Started on the da850evm, now using a custom board with lots of codecs.

We are not using codec engine at all. We implement our own algorithm on the DSP side. For now, we haven't seen any trouble with dsplink except for audio capture.

I also try today some audio capture with "arecord" with a Linux kernel 3.6.9 from kernel tree on the Experimenter Kit. But as you guess, without much success as I supposed!

We also use a custom board based on the LogicPD OMAP L138 SOM. Unfortunately, we have exactly the same behaviour for audio capture as we have with the experimenter kit. To be sure troubles are not coming from the SOM, I bought an OMAP L138 LCDK today. I will do some audio capture testing next week and keep you in touch about the results.

On one side, I would be pleased to see audio capture working with Linux and ALSA on the LCDK but on the other side it would imply the design of our own SOM. Which will not be easy for sure.

Many thanks again for your support.

Have a nice week-end!

Hi,

We're using the OMAP-L138 SOM with WinCE6.0 and DSPLINK.  I've looked everywhere for example code compatible with DSPLINK that will help us get started with DSP capture of data from the on-board AIC3106 on the LogicPD EVM.  Changes would need to be made in the OSD and possibly the BSP, but beyond that, I have no idea where to begin.  Could anyone please point me to some relevant code? 

Thanks much.  D.M.

There is an Audio SOC example that is targeted for the OMAP-L138 device that run Linux the main GPP core. Assuming, you validated and have DspLink samples application's running on your setup.  This should be a good stating point. http://processors.wiki.ti.com/index.php/Audio_Soc_example

NOTE: Beside DSP/BIOS 5.x and DspLink, the DSP-side Audio SOC application requires an EDMA3 Low-Level Driver and DSP/BIOS Platform Support Package for BIOS5.x for it to build successfully .  All these packages are provided in the Linux DVSDK for the OMAP-L138 but can be separately downloaded from TI's Embedded Target Content page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html

I see similar question was also post at:

http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/262908.aspx

Can you mark this thread as answered and we'll continue any further discussions in the other post.

Thanks,

To get back on the linux side, the problem is most likely in the IRQ routine in the davinci-pcm driver. The ping-pong just makes matters complex, and would help in DDR RAM latency issues, but it does not take away the real-time demand on the IRQ routine, which must update the DMA parameters before the next transfer occurs, which can be within a few milliseconds because the buffer sizes are quite small.

I've experimented with a setup where the DMA controller just loops through 8 round-robin linked param sets and the IRQ is only used to send progress notifications to user space. That, in combination with a 4MB DMA buffer, completely eliminated underruns. I can now record 16 channels of 32-bit audio data and write it to an SD card without overruns.