CPU usage about gstpgm HOT 4 OPEN

It usually implies the PGM settings are not suitable for the platform or
the platform's timer is unstable at high resolution and thus spin waiting
at 100% CPU. It needs a bit of trail and error trying different timers and
settings.

On Tue, Jun 10, 2014 at 12:22 PM, Reuben Martin [email protected]
wrote:

First, thanks for porting this to the newer Gstreamer and OpenPGM APIs.
I've been trying it out, and when I do there is always one CPU that gets
totally maxed out by one of the threads. Changing only the sink to a normal
udpsink doesn't produce the same load, so it's not the encoder.

Is this normal? It's hard to imagine that PGM would eat up this much cpu
time...

Reply to this email directly or view it on GitHub
#3.

from gstpgm.

Are you speaking of settings used within the source code, or configurable settings exposed by the gstreamer interface?

from gstpgm.

The last two patches added most of the configurable options so there should
be plenty to play with.

On Tue, Jun 10, 2014 at 2:03 PM, Reuben Martin [email protected]
wrote:

Are you speaking of settings used within the source code, or configurable
settings exposed by the gstreamer interface?

Reply to this email directly or view it on GitHub
#3 (comment).

from gstpgm.

I've been toying with various configuration options trying to fix this. After some reading I thought this might be due to the clock source itself rather than any config settings. But I've not been able to force the clock source. Whenever PGM_TIMER is defined in the environment (even when defined as an empty string) the pgmsink module fails to load. Is this a bug, or do I need to do something different to change the clock source to something like HPET or RTC?

from gstpgm.