<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX ProcessorsのトピックGetting precise frame counts in alsa drivers on imx6q platform</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/Getting-precise-frame-counts-in-alsa-drivers-on-imx6q-platform/m-p/741640#M115439</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am running a Yocto kernel (3.14.52 with PREEMPT_RT patch) on an imx6q board with 2 audio outputs :&lt;/P&gt;&lt;P&gt;- hdmi (via HDMI phy transmitter)&lt;/P&gt;&lt;P&gt;- jack ( via TLV320DAC32 chip)&lt;/P&gt;&lt;P&gt;The middleware running on top of the kernel (and the alsa lib) needs accurate delay (difference between hardware pointer and application pointer) to synchronize video rendering with audio stream.&lt;/P&gt;&lt;P&gt;Unfortunately, the hardware pointer is updated each time a DMA transfer has been completely done. This gives an unacceptable step effect.&lt;/P&gt;&lt;P&gt;The hardware can not provide a frame count of the audio rendering. Besides, there is not possibility to get a progress estimation of the DMA transfer. In these conditions, it is not amazing that&amp;nbsp; the residue granularity in the driver/alsa framework is set to DMA_RESIDUE_GRANULARITY_SEGMENT and not DMA_RESIDUE_GRANULARITY_BURST.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have found a solution based on capturing timestamps to retrieve frame count, knowing the frame rate.&lt;/P&gt;&lt;P&gt;Did anyone experiment a more pretty solution?&lt;/P&gt;&lt;P&gt;Thank you.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 22 Jan 2018 13:17:32 GMT</pubDate>
    <dc:creator>fred35</dc:creator>
    <dc:date>2018-01-22T13:17:32Z</dc:date>
    <item>
      <title>Getting precise frame counts in alsa drivers on imx6q platform</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Getting-precise-frame-counts-in-alsa-drivers-on-imx6q-platform/m-p/741640#M115439</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am running a Yocto kernel (3.14.52 with PREEMPT_RT patch) on an imx6q board with 2 audio outputs :&lt;/P&gt;&lt;P&gt;- hdmi (via HDMI phy transmitter)&lt;/P&gt;&lt;P&gt;- jack ( via TLV320DAC32 chip)&lt;/P&gt;&lt;P&gt;The middleware running on top of the kernel (and the alsa lib) needs accurate delay (difference between hardware pointer and application pointer) to synchronize video rendering with audio stream.&lt;/P&gt;&lt;P&gt;Unfortunately, the hardware pointer is updated each time a DMA transfer has been completely done. This gives an unacceptable step effect.&lt;/P&gt;&lt;P&gt;The hardware can not provide a frame count of the audio rendering. Besides, there is not possibility to get a progress estimation of the DMA transfer. In these conditions, it is not amazing that&amp;nbsp; the residue granularity in the driver/alsa framework is set to DMA_RESIDUE_GRANULARITY_SEGMENT and not DMA_RESIDUE_GRANULARITY_BURST.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have found a solution based on capturing timestamps to retrieve frame count, knowing the frame rate.&lt;/P&gt;&lt;P&gt;Did anyone experiment a more pretty solution?&lt;/P&gt;&lt;P&gt;Thank you.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 22 Jan 2018 13:17:32 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Getting-precise-frame-counts-in-alsa-drivers-on-imx6q-platform/m-p/741640#M115439</guid>
      <dc:creator>fred35</dc:creator>
      <dc:date>2018-01-22T13:17:32Z</dc:date>
    </item>
  </channel>
</rss>

