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.

Audio on OMAP35X

Hi,

I have the sample audio application for ALSA (captures the voice from Mic input) which works fine on the PC.When ported on OMAP35x it doesnt seem to behave the same.

The captured data is full of noise. Similar is the case with playback sample application too.

Is any customization required for the board though the ALSA driver used by board(cross compiled for board) and the PC is same.

I was trying to capture data at a sampling rate of 8000Hz , mono type,16 bit Little Endian format

Any suggestions would be of great help to me.

Regards,

Teja Atluri.

 

 

  • Teja: I would suggest posting this in the OMAP Forum, as I believe this is more relevant to the community working in that forum.

  • Though I am not familiar with the example you mention I can say that the SDK 1.0 ALSA driver should support 8KHz mono 16bit little endian signed PCM data, my understanding of ALSA is that it should work roughly the same on various underlying hardware as long as the format in use is supported.

    Just to verify this is not a hardware issue you could try doing an audio pass through with 'cat /dev/dsp > /dev/dsp'.

  • Hi,

     

    I haven't got time to check this one on the EVM, but the board won't ahve the /dev/dsp device unless the kernel has OSS-compatibility enabled...

     

    I will check the alsamixer settings for the gain controller in the capture, and to review the mapping of the input capture switch to be sure you are selecting the proper device input. It would be worth to review the TWL4030 or equivalent datasheet to gain some light on it. I had a similar problem for Davinci with alsa and it turns out I didn't had the right input switch turned on into the PGA.

     

    Regards,

     

    Diego Dompe

    RidgeRun Engineering

  • Hi,
     
    Yeah. The board doesnt have the /dev/dsp device . The default kernel image that came with the board does not have the OSS comaptibility enabled. I shall see if I can enable OSS compatibility and build kernel image
     
    The sample application now works after configuring the device for the near_period_size and buffer size.
    Im trying to bring up a  VoIp application, which makes me read 320 bytes of data for each snd_pcm_readi  operation , as per VoIp standards. With this, I often end up with a Broken pipe error. Though i handle this...the  pause in the voice is very much significant at the other end....
     
    With a larger buffer ALSA seems to be much stable.. Any suggestions on this!!...  
     
    Thank You all for the reply.. and yeah i shall look into the datasheet and check out.
     
    Regards,
    Teja.
  • Hi,

    This reply is a bit late  but I wanted to throw in my 2 cents because I have a related question...   I believe buffer underruns can cause noise problems in this environment also, and depending on what is going on with your system, this may or may not be the problem.  Bottom line is that bigger buffers make for less buffer errors; however, (and this is the segway into my question) with that comes latency... 

    I purchased an OMAP-EVM from Mistral, and while waiting for it to arrive, I used a loaner from my TI rep.  I installed everything from scratch using UART3 to boot and load barebones (following procedure of chap5 of the getting started guide).  I installed all the stuff from the Mistral site, installation went well and linux booted standalone just fine.    My next step was to use ALSA to build a single program that would do audio loopback (basically a snd_pcm_readi/snd_pcm_writei loop in C).  After hacking away at aplay.c I got this to work. 

    A few days later (i.e. yesterday) I received my board from Mistral with OS and everything pre-installed.  So I set it up and tried my audio loopback program and immediately noticed that there was about a 1-second of delay between audio input and output (I had a mic/preamp for input and headphones for output).  The exact same executable had very different latency.    I'm assuming that the driver must be built with different amounts of pre-configured buffering or something like that (haven't had a chance to look into this yet).  Anyone know what would cause this?

    Thanks,

    Ed