• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 96 subscribers
  • Views 485 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem with 32-bit audio on OMAP L137 EVM

Rico Schulze
Intellectual 480 points
Other Parts Discussed in Thread: OMAP-L137, OMAP-L138

Hello,

I am using the audio example of the PSP version 1.30 with the OMAP L137 EVM board. The code was modified like described in post http://e2e.ti.com/support/embedded/f/355/p/42576/165541.aspx#165541to use the 32-bit mode of the codec in a non-interleaved stream. The data of the stream seems to be fine as well as the sound that is looped back. The mysterious thing happen when I modify the data of the xmt array for example by silencing the first element by:

/* copy the receive information to the transmit buffer                */
memcpy(xmt,rcv,BUFSIZE * RX_NUM_SERIALIZER);
/* set first element                                                                           */
*((Int32 *)xmt)=0;

This example results in a strong noise on both audio channels. All attempts to modify the output stream results in a noisy output. For me it seems that there is some hidden connection between input and output stream.

Is there some workaround for this problem?

Thank you!

  • 0
    TI__Genius 14545 points

    Rico,

       I would suggest to put the McASP is digital loopback mode to isolate the issue this to a software issue. You can then look at the data you received back from the loopback and compare it to the data that you send to the serializers. This will probably result in a lot of insight into what is occuring. For the I2S protocol, if the most significant bit of wrong you will hear a lot of noise.

  • 0 in reply to dabuan
    Intellectual 480 points

    Drew,

    Thanks for your suggestion. The McASP data is fine in the digital loopback mode. Probably this is an AIC310 configuration issue. Again, as long as the received stream is not modified after it was copied to xmt the audio output is fine. I played a little bit around with the data and found that the increase by one (normally you should not notice this acoustically) of a single value of the xmt array completely destroy the sound of one channel whereas setting a single 32-bit value to zero destroys the sound of both channels. Do you maybe have another idea what could be wrong?

    Thank you,

    Rico

  • 0 in reply to Rico Schulze
    TI__Genius 14545 points

    Rico, 

       I'm not familiar with the Spectrum Test case, but the McASP on the OMAP-L137 has been highly tested in various different audio products - so it sounds like a configuration issue. I agree that incrementing the audio data should not result in an audio difference (unless you are dealing with the MSb of the I2S stream.) Check the McASP status registers to see if there are any errors present. Transmit underruns are a common cause of errors since they must be serviced in a particular time window.

       Also, from what I remember the Spectrum Test case uses polling to check when the input audio is available. Since audio it time sensitive, I would argue that this is not the best method. If you want, You can tweak the McASPEcho program from the quickStartOMAPL1x project to run with the OMAP-L137. (It was developed/tested on the OMAP-L138 platform from Logic PD). You should be able to re-configure the base address of some of the pointers and get it running on the OMAP-L137. Otherwise you can just use it as a reference.

     

  • 0 in reply to dabuan
    Intellectual 480 points

    Drew,

    The codec seems to be not in the 32-bit mode as it was supposed to be by using the configuration in post http://e2e.ti.com/support/embedded/f/355/p/42576/165541.aspx#165541. An working example in the PSP with 32-bit AD conversion would be nice. Is there a simple way to read from the codec registers without rewriting the majority of the code?

    Thanks,

    Rico

  • 0 in reply to Rico Schulze
    TI__Genius 14545 points

    Rico,

       The only way to read from the Codec (as configured on the board) is per I2C (You can confirm with the AIC3106 datasheet for other modes). There might be an I2C driver in the PSP packet that you can utilize to read from the codec. Otherwise, you use the I2C Write/Read functions from the McASP Echo project to check the register settings. You should be able to pull all the memory from the AIC3106 into a buffer on the OMAP-L137 using the drivers.