3 Replies Latest reply on Jun 16, 2020 3:46 AM by HemanthR_06

    About composite device class DMA buffer estimation   for CX3/FX3

    NoAr_1540581

      Hello

       

      I would like to realize a system using UVC and UAC as a composite device only with CX3 without using FPGA. However, as described in the About composite device class for CX3/FX3 , I am considering a system that does not have loss of audio data.

      Also, i am understanding that it should be use the DMA buffer separately for UVC and UAC. If I consider half of SRAM 512k as the FW area, we think that approximately 300kByte can be allocated to the DMA buffer.

      Q1) How many DMA buffer bytes should be prepared for each of UAC and UVC so that no data loss occurs? It is no problem to estimate the transfer band of UVC as 480Mbps. In addition, I would like to know the effective UVC transfer band when there is no audio data loss

      Please tell me the recommended DMA buffer size for UAC and UVC.


      Q2) Please find attached,the internal configuration of the CX3 is as attached, but if it is incorrect, please let me know.Especially, the route that sends data as UAC from microphone input,etc

      Q3) The period during which audio data can be sent to the host is "! FV", but does this mean that audio data can be sent only during the video blanking period?

       

      Q4) I found the UAC and UVC sample program for FX3, but is there the UAC sample firmware for CX3?

       

      Best Regards

      arai

        • 1. Re: About composite device class DMA buffer estimation   for CX3/FX3
          HemanthR_06

          Q1) How many DMA buffer bytes should be prepared for each of UAC and UVC so that no data loss occurs? It is no problem to estimate the transfer band of UVC as 480Mbps. In addition, I would like to know the effective UVC transfer band when there is no audio data loss

          Please tell me the recommended DMA buffer size for UAC and UVC.

          >> In the UAC example that we have in FX3 SDK the DMA channel, that is used for UAC, uses 96 bytes buffer size with buffer count 16. This example reads stored audio data from the SPI Flash and copy the read data into UAC DMA channel buffers.

           

          When this method is used along with UVC, you need to test the performance. Based on that DMA buffers needs to be changed.

           

          As we do not have a standard reference example for UVC+UAC we cannot recommend the DMA buffer size.

           

          Q2) Please find attached,the internal configuration of the CX3 is as attached, but if it is incorrect, please let me know.Especially, the route that sends data as UAC from microphone input,etc

          >> When you use CX3 the sensor should send the video data over MIPI interface and not GPIF. Using SPI for Audio is fine.

           

          Q3) The period during which audio data can be sent to the host is "! FV", but does this mean that audio data can be sent only during the video blanking period?

          >> On USB bus both can happen at the same time. Bandwidth will be shared between audio and video data.

          Q4) I found the UAC and UVC sample program for FX3, but is there the UAC sample firmware for CX3?

          >> We do not have sample project for CX3. But UAC sample project of FX3 can work on CX3 also.

           

          Regards,

          Hemanth

          • 2. Re: About composite device class DMA buffer estimation   for CX3/FX3
            NoAr_1540581

            Hello Hemanth san

             

            Thank you for your reply.

             

            > In the UAC example that we have in FX3 SDK the DMA channel, that is used for UAC, uses 96 bytes buffer size with buffer >count 16. This example reads stored audio data from the SPI Flash and copy the read data into UAC DMA channel buffers.

            >

            → This time the audio must be input in real time from the microphone. Is it possible to save the A/D converted data in the DMA buffer without data loss?The transfer band of UVC is equivalent to USB2.0, so I don't think that a buffer area is needed so much.From the above, I would like to divide the DMA buffer into two and use it for UVC (ex. 200KByte) and for UAC (ex.50KByte). UVC does not need the USB3.0 band, and there is no problem in the band of about 300 Mbps, so I think that it is not necessary to keep the DMA buffer area so much. Therefore, if I can keep the 50Kbye area for UAC, I think that data loss due to overwriting of audio data will not occur.

            Q1)

            If there is a possibility that audio data may be overwritten even with the above number of bytes, please tell me the reason.

             

            Q2)

            Actually, I understand that I need to do a test, but as a preliminary consideration stage, please tell me from the above how much DMA buffer size of UAC and UVC each should be in theory.

             

            Q3)

            Regarding the previous attached PowerPoint (composite.pdf), is the channel and endpoint configuration correct?

            Please tell me if the configuration is wrong.

            Also, In Example of UVC and UAC in single project?  is explanation the two channels/pipes is divided into two, but is it ok to think that channels and thread 0/1(attached file) same meaning?

             

            Bets Regards

            arai

            • 3. Re: About composite device class DMA buffer estimation   for CX3/FX3
              HemanthR_06

              > In the UAC example that we have in FX3 SDK the DMA channel, that is used for UAC, uses 96 bytes buffer size with buffer >count 16. This example reads stored audio data from the SPI Flash and copy the read data into UAC DMA channel buffers.

              >

              → This time the audio must be input in real time from the microphone. Is it possible to save the A/D converted data in the DMA buffer without data loss?The transfer band of UVC is equivalent to USB2.0, so I don't think that a buffer area is needed so much.From the above, I would like to divide the DMA buffer into two and use it for UVC (ex. 200KByte) and for UAC (ex.50KByte). UVC does not need the USB3.0 band, and there is no problem in the band of about 300 Mbps, so I think that it is not necessary to keep the DMA buffer area so much. Therefore, if I can keep the 50Kbye area for UAC, I think that data loss due to overwriting of audio data will not occur.

              Q1)

              If there is a possibility that audio data may be overwritten even with the above number of bytes, please tell me the reason.

              >> FX3 acts as SPI Master for Audio interface. Let us say, as you said, we have two buffers of 25KB each (total of 50KB). Then after one buffer is full, there will be a delay before the data can be written into next buffer. During this time, data can't be taken into FX3 from SPI. If this is okay, then yes, it can be tried.

               

               

              Q2)

              Actually, I understand that I need to do a test, but as a preliminary consideration stage, please tell me from the above how much DMA buffer size of UAC and UVC each should be in theory.

              >> Audio data comes into FX3 at a maximum rate of 5MBps. So, if on the USB side, the audio data is read out at a sufficiently larger rate than 5MBps, then mentioned DMA buffer sizes should be okay.

               

              Q3)

              Regarding the previous attached PowerPoint (composite.pdf), is the channel and endpoint configuration correct?

              Please tell me if the configuration is wrong.

              Also, In Example of UVC and UAC in single project?  is explanation the two channels/pipes is divided into two, but is it ok to think that channels and thread 0/1(attached file) same meaning?

              >> As I mentioned the diagram looks correct if it is FX3 instead of CX3. The suggestion in the thread meant both the channels having producers as P-Port (this is when FPGA is involved). If there is no FPGA, as in your case and if the data has to come from SPI, then your diagram is okay.

               

              Regards,

              Hemanth