On 10.03.2016 02:54, glenvt18 wrote:

Hi folks,

I've found that with some DVB tuner drivers poll() returns when there are only small (1-3) number of TS packets available to read(). This results in high CPU usage of the TS buffer thread which is busy reading small chunks of data in cTSBuffer::Action(). 2 out of 3 tuners I tested were affected with this issue. Even with a "good" tuner TS buffer thread CPU usage is up to 10% per HD stream on ARM Cortex-A7. With the proposed patch it is below 1-2% on all ARM and x86_64 platforms I've tested. The delay value of 10 ms can be considered safe:

media/dvb-core/dmxdev.h:109 #define DVR_BUFFER_SIZE (10*188*1024)

It will take a tuner to receive (10*188*1024)*8*(1000/10) / 1000000 = 1540 Mbit/s to overflow the device buffer within 10 ms interval. A smaller delay is not enough for ARM. cDvbDevice has a ring buffer of 5MB which is larger.

This patch was made against VDR 2.3.1, but it can be applied to VDR 2.2.0 as well.

Please review. glenvt18

---

Index: b/device.c

--- a/device.c 2015-09-18 01:04:12.000000000 +0300 +++ b/device.c 2016-03-10 03:38:50.078400715 +0300 @@ -1768,6 +1768,8 @@ break; } }

•          else
  

•             cCondWait::SleepMs(10);
            }
         }
   }
  

I'm not too fond of the idea of introducing an additional, unconditional wait here. The actual problem should be fixed within the drivers. However, maybe waiting in case there is only a small number of TS packets available is acceptable:

--- device.c 2015/09/05 11:42:17 4.2 +++ device.c 2016/03/10 09:34:11 @@ -1768,6 +1768,8 @@ break; } } + else if (r < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE) + cCondWait::SleepMs(10); } } }

The number MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE is just a random pick to avoid using a concrete literal number here. Can you please test if this still solves your problem?

Klaus