OMAP-L138 / C6748 LCDK mcASP Demo - Problem with audio buffer

Sascha Bucksch

Other Parts Discussed in Thread: OMAPL138, REG102, REG101

Hi everyone,

I've started working with the C6748 LCDK for the first time and installed the OMAPL138 Starterware (version 1_10_04_01) and opened the mcASP Demo, which transfers the signals from Line-In to Line-Out with the help of the aic31 codec in connection with the EDMA3 low-level-driver.

Now I'm trying to design a low pass filter into the main program. The problem i have is to work with the audio buffer.

As I figured out the audio data is transfered into the rxBuf's. I've limited the transfer to one buffer, so I'm only working with the rxBuf0. I also put the word size to 8 and sampling rate to 8000. So each data received in the rxBuf consists of 8 bit, which are ordered in the array as integer values between 0x0 and 0xFF. But every second value in the array is set to 0.

For example:

rxBuf0[0] = 0x02

rxBuf0[1] = 0x00

rxBuf0[2] = 0x04

rxBuf0[3] = 0x00

The output buffer is the txBuf0. When I just copy the input buffer rxBuf0 to txBuf0, the sound works fine. But when i manipulate the data in rxBuf0 with a low pass filter, the sound is very distorted. The low pass filter is a simple FIR filter, which is working on other boards.

My question is: Why is every second value in the buffer set to zero? When i change the word size to 16, then every 3rd and 4th value is zero. I can't figure out the way, the buffer is working.

Best regards

Sascha

over 11 years ago

0 Sivaraj Kuppuraj over 11 years ago

TI__Mastermind 35645 points

Hi Sascha,

Thanks for your post.

Actually, if you try configuring different sample rate, data format and slot width, appropriately, you need to set the same thru. CodecRegWrite() API, for example, if you change the data type and slot width, you need to set the corresponding AIC3106 codec registers appropriately for the set data type and slotwidth like as below:

/* Write the data type and slot width */

CodecRegWrite(baseAddr, AIC31_P0_REG9, (dataType | slot));

/* valid data after dataOff number of clock cycles */

CodecRegWrite(baseAddr, AIC31_P0_REG10, dataOff);

For the above value to configure for data type and slot width, you need to refer the AIC3106 codec datasheet and check for appropriate codec registers and corresponding values need to set. Please refer the aic3106 codec datasheet as below:

http://www.ti.com/lit/ds/symlink/tlv320aic3106.pdf

Like wise, for the sample rate configuration, if you change the sample rate to 8000, the appropriate fs will be derived from the below equation:

fs = (PLL_IN * [pllJval.pllDval] * pllRval) /(2048 * pllPval).

a and appropriately, you need to set the sample rate through codec register API as below:

/* Set the sample Rate */

CodecRegWrite(baseAddr, AIC31_P0_REG2, temp);

CodecRegWrite(baseAddr, AIC31_P0_REG3, 0x80 | pllPval);

/* use PLL_CLK_IN as MCLK */

CodecRegWrite(baseAddr, AIC31_P0_REG102, 0x08);

/* Use PLL DIV OUT as codec CLK IN */

CodecRegBitClr(baseAddr, AIC31_P0_REG101, 0x01);

For all the above code, please refer the aic31.c source file from the below installed path:

~ti\OMAPL138_StarterWare_1_10_03_03\examples\evmOMAPL138\mcasp\aic31.c

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
-------------------------------------------------------------------------------------------------------

0 Sascha Bucksch over 11 years ago in reply to Sivaraj Kuppuraj

Prodigy 40 points

Hi Sivaraj,

Thank you for your reply, but unfortunately this doesn't solve my problem. When i set back all settings as they were in the demo before (word size 16, sampling rate 48000), the rxBuf0 looks like this:

rxBuf0[0] = 0x02

rxBuf0[1] = 0x04

rxBuf0[2] = 0x00

rxBuf0[3] = 0x00

rxBuf0[4] = 0x02

rxBuf0[5] = 0x02

This values are examples, but the zero bits like in rxBuf0[2] and rxBuf0[3] are constantly repeating. Is the information in the buffer rxBuf the real uncompressed audio data or is it compressed in some why so i have to decompress or deserialize it to work with my low pass filter? As far as i know the I2S interface is alternating between left and right channel.

Best regards

Sascha

0 Sivaraj Kuppuraj over 11 years ago in reply to Sascha Bucksch

TI__Mastermind 35645 points

Hi Sascha,

Thanks for your update.

The actual audio data from ADC of AIC3106 codec should be in the form of compressed data and through I2S interface, the McASP receives data from the ADC in the form of compressed audio data through its RxBuf[0]. May be, you would have the necessity to decode/decompress the audio data from the McASP Tx/Rx buffer to use it for the low pass filter and you are right that, I2S codec interface is alternating between left and right channels.

Thanks & regards,

Sivaraj K

0 Sascha Bucksch over 11 years ago in reply to Sivaraj Kuppuraj

Prodigy 40 points

Hi Sivaraj,

Thanks for your answer. Like you said the data seems to be compressed, because the i2s transfer seems to have some offset bits, which could explain the zero fills in the rxbuf0 buffer.

With the help of the datasheet for the AIC3106 Codec you posted, i have found a new way to realize my filter with the help of the AIC3106 codec instead of manipulating the data in the buffers directly.

Thanks and best regards

Sascha

0 Nadav Benedek over 9 years ago in reply to Sascha Bucksch

Prodigy 240 points

Hi Sascha,
It would be highly appreciated if you can add the project zip to here to see how you implemented the filter.

Processors

Processors forum

OMAP-L138 / C6748 LCDK mcASP Demo - Problem with audio buffer