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.

  • Resolved

OMAP4460 Blaze tablet 4 mic capture has audio capture losses.

Intellectual 805 points

Replies: 9

Views: 4675

Hi all,

I am using tinycap to capture signals from 4 digital mics present in OMAP4460 Blaze tablet .

My tinycap settings are as follows.

tinycap /sdcard/test.pcm -D 0 -d 0 -c 4 -r 48000 -b 32 -p 768 -n 10

The data do get captured on four digital microphones but i see many audio losses in the captured signal.

1) What is the reason for the audio losses.

2) What si the maximum data size that can be allocated to store the captured data ( i.e. period_size * number_of_buffers * sizeof( WORD32) ).

3} how can i stop the Audio loss

  • Hello Sreenivasa,

    1) What is the reason for the audio losses.
    3} how can i stop the Audio loss
    - I assume that the audio loss is caused by your TinyAlsa configurations. Please provide more information about your use case.

    2) What si the maximum data size that can be allocated to store the captured data ( i.e. period_size * number_of_buffers * sizeof( WORD32) ).
    - config.format = PCM_FORMAT_S32_LE; Therefore the maximum data size is 32.

    unsigned int capture_sample(FILE *file, unsigned int device,
    unsigned int channels, unsigned int rate,
    unsigned int bits)
    {
    struct pcm_config config;
    struct pcm *pcm;
    char *buffer;
    unsigned int size;
    unsigned int bytes_read = 0;
    config.channels = channels;
    config.rate = rate;
    config.period_size = 1024;
    config.period_count = 4;
    if (bits == 32)
    config.format = PCM_FORMAT_S32_LE;
    else if (bits == 16)
    config.format = PCM_FORMAT_S16_LE;
    pcm = pcm_open(0, device, PCM_IN, &config);
    if (!pcm || !pcm_is_ready(pcm)) {
    fprintf(stderr, "Unable to open PCM device (%s)\n",
    pcm_get_error(pcm));
    return 0;
    }

    Best regards,
    Yanko

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

            Be sure to read the OMAP Application Processors Forum Guidelines and FAQ

  • In reply to Yanko Todorov-XID:

    Hi Yanko,

    Thanks for the reply.
    I am adding details for your query.

    I ) I am using OMAP4 blaze tablet with the OS version 4.1.1 android. I want to capture 4 digital mic signals for beam-forming application.
    All the microphone signals are expected to be in sync and without any audio-loss or distortion.

    While trying to use tinycap to capture 4 mic signals, I do only tinymix settings. The current tinymix settings are as follows:

    "
    Number of controls: 73
    ctl type num name value
    0 ENUM 1 DL1 Equalizer Flat response
    1 ENUM 1 DL2 Left Equalizer Flat response
    2 ENUM 1 DL2 Right Equalizer Flat response
    3 ENUM 1 Sidetone Equalizer Flat response
    4 ENUM 1 AMIC Equalizer High-pass 0dB
    5 ENUM 1 DMIC Equalizer High-pass 0dB
    6 INT 1 DL1 Media Playback Volume 118
    7 INT 1 DL1 Tones Playback Volume 120
    8 INT 1 DL1 Voice Playback Volume 120
    9 INT 1 DL1 Capture Playback Volume 0
    10 INT 1 VXREC Media Volume 0
    11 INT 1 VXREC Tones Volume 0
    12 INT 1 VXREC Voice DL Volume 0
    13 INT 1 VXREC Voice UL Volume 0
    14 INT 1 AUDUL Media Volume 0
    15 INT 1 AUDUL Tones Volume 0
    16 INT 1 AUDUL Voice UL Volume 120
    17 INT 1 AUDUL Voice DL Volume 0
    18 INT 1 SDT UL Volume 101
    19 INT 1 SDT DL Volume 120
    20 INT 2 DMIC1 UL Volume 149 149
    21 INT 2 DMIC2 UL Volume 149 149
    22 INT 2 DMIC3 UL Volume 149 149
    23 INT 2 AMIC UL Volume 120 120
    24 INT 2 BT UL Volume 126 126
    25 BOOL 1 DL1 Mono Mixer Off
    26 BOOL 1 AUDUL Mono Mixer Off
    27 BOOL 1 DL1 MM_EXT Switch Off
    28 BOOL 1 DL1 BT_VX Switch Off
    29 BOOL 1 DL1 PDM_DL2 Switch On
    30 BOOL 1 DL1 PDM Switch Off
    31 BOOL 1 Sidetone Mixer Capture Off
    32 BOOL 1 Sidetone Mixer Playback On
    33 BOOL 1 Capture Mixer Tones Off
    34 BOOL 1 Capture Mixer Voice Playback Off
    35 BOOL 1 Capture Mixer Voice Capture Off
    36 BOOL 1 Capture Mixer Media Playback Off
    37 BOOL 1 Voice Capture Mixer Tones Playback Off
    38 BOOL 1 Voice Capture Mixer Media Playback Off
    39 BOOL 1 Voice Capture Mixer Capture Off
    40 BOOL 1 DL1 Mixer Tones On
    41 BOOL 1 DL1 Mixer Voice Off
    42 BOOL 1 DL1 Mixer Capture Off
    43 BOOL 1 DL1 Mixer Multimedia On
    44 ENUM 1 MUX_VX1 None
    45 ENUM 1 MUX_VX0 None
    46 ENUM 1 MUX_UL11 None
    47 ENUM 1 MUX_UL10 None
    48 ENUM 1 MUX_UL07 None
    49 ENUM 1 MUX_UL06 None
    50 ENUM 1 MUX_UL05 None
    51 ENUM 1 MUX_UL04 None
    52 ENUM 1 MUX_UL03 DMic1R
    53 ENUM 1 MUX_UL02 DMic2R
    54 ENUM 1 MUX_UL01 DMic0R
    55 ENUM 1 MUX_UL00 DMic0L
    56 INT 2 Capture Preamplifier Volume 1 1
    57 INT 2 Capture Volume 4 4
    58 INT 2 Aux FM Volume 3 3
    59 INT 2 Headset Playback Volume 15 15
    60 INT 2 Handsfree Playback Volume 26 26
    61 INT 1 Earphone Playback Volume 14
    62 ENUM 1 Headset Power Mode Low-Power
    63 BOOL 1 Earphone Playback Switch Off
    64 BOOL 1 Aux Right Playback Switch Off
    65 BOOL 1 Aux Left Playback Switch Off
    66 ENUM 1 Headset Right Playback Off
    67 ENUM 1 Headset Left Playback Off
    68 ENUM 1 Handsfree Right Playback Off
    69 ENUM 1 Handsfree Left Playback Off
    70 ENUM 1 Analog Right Capture Route Headset Mic
    71 ENUM 1 Analog Left Capture Route Headset Mic
    72 ENUM 1 TWL6040 Power Mode Low-Power

    "

    2) With regard to maximum data size, i meant the buffer_size for alsa and not the bit resolution format.
    My understanding is that with the larger buffersize audio loss problem can be avoided. But it appears that the product of number_of_periods (-p) and period_size (-n) is limited to about 8000. If it could be more or the bit resolution could be reduced or the sampling rate supported could be reduced , the loss issue could be avoided.

    Please advice what should do to avoid this audio loss problem.



    Regards,
    Sreenivasa
  • In reply to sreenivasa upadhyaya:

    Hello Sreenivasa,

    Data from digital microphones can be captured in two ways:

    - Directly from the OMAP's DMIC peripheral. Data is recorded at the native params (96 or 192kHz, 32-bits, 4-ch)

    - Through the ABE's MM_UL. Data is recorded at the ABE frontend's parameters (e.g. 48kHz, 16-bits, 4-ch)

    Which ways do you use in your case?

    I believe you are using the ABE's MM_UL frontend as per the tinymix settings.

    When you say audio loss, do you mean ALSA overruns? The buffer size of 8000 frames is equivalent to 166ms (assuming recording is at 48kHz). That's a large buffer in my opinion, and shouldn't cause ALSA overruns. Take into account that the larger the buffer the more the latency.

    What userspace component is reading the dmic data? The AudioHAL? Have you tried recording using tinycap?

    ALSA overruns depend a lot on the pace at which the userspace reads the data from the ALSA buffer. You might want to measure the time taken between the end of a pcm_read() and the start of the next.

    Best regards,

    Yanko

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

            Be sure to read the OMAP Application Processors Forum Guidelines and FAQ

  • In reply to Yanko Todorov-XID:

    Hi Yanko,

    Thanks for the reply.

    1) I use ABE`s MM_UL in my case.

    As you mentioned - " Through the ABE's MM_UL. Data is recorded at the ABE frontend's parameters (e.g. 48kHz, 16-bits, 4-ch) ",

    but I am not able to capture @ 16 bits / sample in this scenario.
    I am using tinycap and I have mentioned the exact tinycap command used by me in the first thread post.

    2) I have to clarify about my query.

    I did not tell that the buffer size is equivalent to 8000 frames!
    I am quoting my tinycap command again.
    " tinycap /sdcard/test.pcm -D 0 -d 0 -c 4 -r 48000 -b 32 -p 768 -n 10 "

    I would like to know
    ** Is there a limit on the product of -p and -n?
    ** why -b 16 is not allowed?


    Please reply!

    Regards,
    Sreenivasa
  • In reply to sreenivasa upadhyaya:

    Hello Sreenivasa,

    Yes, there is a limit on the ALSA buffer size. See in /kernel/android-3.4/sound/soc/omap/ omap-pcm.c

     static const struct snd_pcm_hardware omap_pcm_hardware = {
             .info                   = SNDRV_PCM_INFO_MMAP |
                                       SNDRV_PCM_INFO_MMAP_VALID |
                                       SNDRV_PCM_INFO_INTERLEAVED |
                                       SNDRV_PCM_INFO_PAUSE |
                                       SNDRV_PCM_INFO_RESUME |
                                       SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
             .formats                = SNDRV_PCM_FMTBIT_S16_LE |
                                       SNDRV_PCM_FMTBIT_S32_LE,
             .period_bytes_min       = 32,
             .period_bytes_max       = 64 * 1024,
             .periods_min            = 2,
             .periods_max            = 255,
             .buffer_bytes_max       = 128 * 1024,
     };

    The maximum buffer size is 128kB. Assuming 4-ch, 32-bits/sample, the max buffer size you can have is 8192 frames.

    Support for 16-bits recording on the MM_UL port was dropped. This was an ABE firmware change. The parameters supported by the MM_UL frontend are in sound/soc/omap/omap-abe-pcm.c (see line in yellow). So you can only record at 32-bits/sample.

    struct snd_soc_dai_driver omap_abe_dai[] = {
             {       /* Multimedia Playback and Capture */
                     .name = "MultiMedia1",
                     .probe = omap_abe_dai_probe,
                     .remove = omap_abe_dai_remove,
                     .suspend = omap_abe_dai_suspend,
                     .resume = omap_abe_dai_resume,
                     .playback = {
                             .stream_name = "MM1 Playback",
                             .channels_min = 1,
                             .channels_max = 2,
                             .rates = SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_44100,
                             .formats = OMAP_ABE_FORMATS,
                     },
                     .capture = {
                             .stream_name = "MM1 Capture",
                             .channels_min = 1,
                             .channels_max = 6,
                             .rates = SNDRV_PCM_RATE_48000,
                             .formats = SNDRV_PCM_FMTBIT_S32_LE,
                     },
                     .ops = &omap_abe_dai_ops,
             },

    For more information see following patches:

    git.omapzoom.org;a=blob;f=sound/soc/omap/omap-pcm.c;h=5a649da9122a3e798713999a766885f0f732a5cd;hb=31b9c766ecb29bbef4b835892ee267ee9aabd21b#l36

    http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=sound/soc/omap/omap-abe-pcm.c;h=183fd47307660ea5e4534824bc8bf98c31910930;hb=31b9c766ecb29bbef4b835892ee267ee9aabd21b#l1442

    Best regards,

    Yanko

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

            Be sure to read the OMAP Application Processors Forum Guidelines and FAQ

  • In reply to Yanko Todorov-XID:

    Yanko,

    Thanks for the reply.

    By auido losses i mean the ALSA overruns.
    How can i prevent them using the tinycap application.

    1) Is this a known issue?

    2 ) Do you have some standard version of tinycap which i can use. if yes please share it.




    Regards,
    Sreenivasa
  • In reply to sreenivasa upadhyaya:

    Hello Sreenivasa,

    The way to discard media storage latency is mounting a ram disk and recording into it:

    # mkdir /data/dmic_rec

    # mount -f tmpfs -o size=100m tmpfs /data/dmic_rec

    # tinycap /data/dmic_rec/rec.wav -D0 -d0 -r48000 -b32 -c4

    How are you checking if ALSA overruns are occurring?

    You can check this by:
    SND_PCM_STATE_XRUN
    The PCM device reached overrun (capture) or underrun (playback). You can use the -EPIPE return code from I/O functions (snd_pcm_writei(), snd_pcm_writen(), snd_pcm_readi(), snd_pcm_readn()) to determine this state without checking the actual state via snd_pcm_state() call. It is recommended to use the helper function snd_pcm_recover() to recover from this state, but you can also use snd_pcm_prepare(), snd_pcm_drop() or snd_pcm_drain() calls.

    -EPIPE - This error means xrun (underrun for playback or overrun for capture). The underrun can happen when an application does not feed new samples in time to alsa-lib (due CPU usage). The overrun can happen when an application does not take new captured samples in time from alsa-lib.

    Best regards,
    Yanko

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

            Be sure to read the OMAP Application Processors Forum Guidelines and FAQ

  • In reply to Yanko Todorov-XID:

    Hello Sreenivasa,

    Do you have progress with check of ALSA overruns?

    Best regards,
    Yanko

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

            Be sure to read the OMAP Application Processors Forum Guidelines and FAQ

  • In reply to Yanko Todorov-XID:

    Dear Yanko,

    Thanks for the active support.

    I will get back after i do the necessary testing.

    Thanks.
    Regards,
    Sreenivasa

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.