• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1217 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.

Audio record problem

marcus lu
Expert 1550 points
Other Parts Discussed in Thread: TVP5158

Hi Sir :

I work on DM8148 platform and use DVRRDK_03.00.00.00 to develop our system.

In our system, we use TVP5158 as audio decoder and aic3106 as encoder.

Recently, we find out a problem when recording audio data.

We use PCM 16bit mode to capture audio data through I2S and use G711 to encode audio data.

When we playback the video and audio data, we find out the audio data sometimes is abnormal, in other words, the audio is mute.

We have checked the audio input signal and we find it works fine when the problem above happens.

We also do a software debug, and we find that when this problem happens the below messages shows.

readAlsaAudio => len : 0, err : -32
DumpAlsaPCMstatus ***
state : XRUN
trigger_timedavinci_pcm: marcus : davinci_pcm_prepare
: 1364380618.42969649
tstamp : 1364380618.47227949
delay : 0
avail : 8203
avail_max : 8203

=> CAPTURE ERROR Broken pipe ...
DumpAlsaPCMstatus ###
state : XRUN
trigger_time: 1364380618.42969649
tstamp : 1364380618.61277350
delay : 0
avail : 8203
avail_max : 0

DumpAlsaPCMstatus @@@
state : PREPARED
trigger_time: 1364380618.42969649
tstamp : 1364380618.65683150
delay : 0
avail : 0
avail_max : 0
=> audioRecordLen : 0, expect_audioRecordLen : 320, time : 1364380618

I do not know if the problem is related with broken pipe, because sometimes when this messages shows, the audio data is good.

When broken pipe happens, we use snd_pcm_prepare function to recovery the audio dma.

We have bothered by this problem few weeks, could some one kindly give us some suggestion or some way to find the bug?

 Best regards,

Marcus

  • 0
    TI__Expert 6950 points

    Audio mute could be due to this ALSA error. Does it recover after sometime?

    Few options you can try -

    1. Use edma EVENTQ_0 for audio. Increase mcasp fifo level to 16.

     Linux/arch/arm/mach-omap2/devices.c

     static struct snd_platform_data tvp5158_snd_data = {

                .tx_dma_offset = 0x46000000,

                .rx_dma_offset = 0x46000000,

                .asp_chan_q     = EVENTQ_2, =>  EVENTQ_0

                .tdm_slots        = 16, /* number of channels */

                .op_mode         = DAVINCI_MCASP_IIS_MODE,

                .num_serializer = ARRAY_SIZE(tvp5158_iis_serializer_direction),

                .serial_dir          = tvp5158_iis_serializer_direction,

                .version            = MCASP_VERSION_2,

                .txnumevt          = 1,

                .rxnumevt          = 1 => 16

    }

     

     Ensure that Q0 / TC0 has highest priority.

    dvr_rdk/mcfw/src_bios6/utils/src/utils_dma_common_cfg.c

     

                    /**

                     * \brief EDMA3 TC priority setting

                     *

                     * User can program the priority of the Event Queues

                     * at a system-wide level.  This means that the user can set the

                     * priority of an IO initiated by either of the TCs (Transfer Controllers)

                     * relative to IO initiated by the other bus masters on the

                     * device (ARM, DSP, USB, etc)

                     */

                        {

                        0u, =>  This should be 0

                        4u,

                        4u,

                        4u,

                        0u,

                        0u,

                        0u,

                        0u

                        },

     

    1. Tune alsa period size, buffer sizes to have max internal driver buffering.

     

  • 0 in reply to Sivagamy Govindasamy
    Expert 1550 points

    Hi Sivagamy :

    I really appreciate your reply.

    About your question and suggestion I describe below. 

    Audio mute could be due to this ALSA error. Does it recover after sometime?

    Yes, it will recover after sometime.

    I have try your suggestion and our system works fine so far.

    I modify Linux/arch/arm/mach-omap2/devices.c and change EVENTQ_2 to  EVENTQ_0, 1 to 16 for rxnumevt.

    I also confirm dvr_rdk/mcfw/src_bios6/utils/src/utils_dma_common_cfg.c and the setting is the same as you suggest.

    However, I observe the log, the broken pipe shows one time but it seems does not cause any problem.

    I wonder if it is the reason why cause this problem.

    I also check the alsa period size and buffer size, we set 1000 for period size and 16000 for buffer size.

    I do not know if the sizes we set are suitable, if you have better idea, please tell us.

    About this issue, we need couple days to do a test and I will let you know the test result.

    By the way, in our custom board, we only use one audio input, so could we only use one channel capture rather than four channels?

    I think this can affect the performance.

    Best regards,

    Marcus 

  • 0 in reply to marcus lu
    TI__Expert 6950 points

    1. Broken issue occurs when app doesnt read the data at the stipulated time. Ensure that you audio threads run at highest priority.  You can further increase rxnumevt (as 32 max I guess) as this translates into mcasp fifo depth.

     

    2. Using one audio input.

    Refer tvp5158 datasheet to know the settings. Looks like min supported is 2 and you might have to change the tvp5158 - audio configuration code in dvr rdk accordingly.