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.

TDA4VM: BT interface transmission delay

Part Number: TDA4VM

Hi,

The problem is described below:

When using bt.1120 interface to transmit 1080p video stream, we found that the delay from tda4 to the receiver to get the data is about 120ms.

·BT.1120 interface configuration:74.25MHz、EMBSYNC.

·Video stream configuration:1080P 25f/s、YUV422.

I have a few questions for you to answer, as follow:

1、The receiver receives duplicate frames. Is this phenomenon unique to BT transmission? If so, how to close it? If not, what causes it?

2、Is BT reception in blocking mode or non blocking mode?

3、Is there a ready-made scheme to optimize the transmission delay?

Looking forward to your reply!

Thank you!

  • Hi hui wang,

    120ms delay is almost 3 frame delay, it cannot be DSS. most likely this is coming due to buffering. How many frames are you enqueueing to the driver? 

    how do you measure 120ms delay? Do you compare the frames received on the other side? 

    No BT does not duplicate the frames.. 

    Regards,

    Brijesh

  • Hi,

    Thank you for your reply!I'm sorry to reply you so late.

    We timestamp the sending and receiving respectively, the delay is determined by the difference of time stamps.

    When debugging demo code, we found that the following function can implement BT sending, as follow:

    ·vxCopyImagePatch

    Then we didn't find where to implement this function, So I have the following questions:

    ·Where is this function implemented of vxCopyImagePatch(Linux+RTOS 7.2)

    · How many frames am i enqueueing to the driver? Where is this part of the driver?(Linux+RTOS 7.2)

    Looking forward to your reply!

    Thank you!

     

  • Hi hui wang3,

    This function is implemented in the file ti-processor-sdk-rtos-j721e-evm-08_00_00_12\tiovx\source\framework\vx_image.c.  It essentially just does memory copy from the input buffer to the vx_image.. Since this is CPU copy, it can take some, but i doubt 120ms. 

    Display typically starts as soon as we enqueue one frame to the drivers. Depending on when VSYNC is generated, there could be at max one frame time period, before it starts outputting the data.. 

    So at max one frame between enqueue of the frame and one frame in transmitting the data and also on the receiving side, when do you receive the data? Do you also have buffer queue on the receiving end?

    Regards,

    Brijesh