Reply to thread

Message

<blockquote data-quote="tourettes" data-source="post: 656586" data-attributes="member: 10858">ep, it should be. But I am hopping that the MMCSS sheduling is fair between the boosted threads, so all the three threads would give good boost over the non-MP threads so background processes would get only the 20% share that is assigened by default (it could be laltered in registry for testing as well).I did some profiling of the dshowhelper's CPU usage - it is not taking that much of the overall CPU usage itself, so the thread boosting should really help for the &quot;lazy&quot; trimer issue. But if the dErr value is less than 1 ms then there is not much that the increased timer / scheduling accuracy will help.About the CPU usage itself: Getting current time (GetCurrentTimestamp() and there the most of the time is spent in MulDiv64 method) is using approx 25% of the time - I guess the code is really agressive when it comes to polling the current time. Not sure if there would be any optimization points - of course using timeGetTime / GetTickCount would use much less CPU but those are too innaccurate. On audio renderer side I managed to get really good accurate just by using a simple SetWaitableTimer(). That allows with the MMCSS sub ms accuracy (at least on my dev PC <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />). Maybe it would be worth trying to use that instead of the aggressive polling. But it would require huge re-write most likely <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />But first we should figure out if the ION's ATOM CPU is to blame or if is the GPU. If it is the CPU then optimizing some code and removing too agressive polling could help. But if it is the GPU -&gt; not worth trying to play around dshowhelper.dll code. There isn't that much DirectX realted that could be done differently.</blockquote>

[QUOTE="tourettes, post: 656586, member: 10858"] ep, it should be. But I am hopping that the MMCSS sheduling is fair between the boosted threads, so all the three threads would give good boost over the non-MP threads so background processes would get only the 20% share that is assigened by default (it could be laltered in registry for testing as well). I did some profiling of the dshowhelper's CPU usage - it is not taking that much of the overall CPU usage itself, so the thread boosting should really help for the "lazy" trimer issue. But if the dErr value is less than 1 ms then there is not much that the increased timer / scheduling accuracy will help. About the CPU usage itself: Getting current time (GetCurrentTimestamp() and there the most of the time is spent in MulDiv64 method) is using approx 25% of the time - I guess the code is really agressive when it comes to polling the current time. Not sure if there would be any optimization points - of course using timeGetTime / GetTickCount would use much less CPU but those are too innaccurate. On audio renderer side I managed to get really good accurate just by using a simple SetWaitableTimer(). That allows with the MMCSS sub ms accuracy (at least on my dev PC :)). Maybe it would be worth trying to use that instead of the aggressive polling. But it would require huge re-write most likely :) But first we should figure out if the ION's ATOM CPU is to blame or if is the GPU. If it is the CPU then optimizing some code and removing too agressive polling could help. But if it is the GPU -> not worth trying to play around dshowhelper.dll code. There isn't that much DirectX realted that could be done differently. [/QUOTE]

Verification