Yep, that is most likely the reason if we are seeing no big gains from MMCSS. Thread that has been boosted with MMCSS should behave well, it shouldn't hog resources. Unfortunately I have already lsot the memory what the EVR presenter's scheduler thread does - but basicly a timing thread shouldn't have that many CPU cycles that it requires for it's work. Some CPU profiling with the EVR presenter side might give us clue where the CPU hogging happens - but I think it wont be worth for the MP1 anymore and MP2 will have completely rewritten EVR presenter code.
MP1 EVR Presenter/dshowhelper community development (4 Viewers)
- Thread starter Owlsroost
- Start date
Yep, that is most likely the reason if we are seeing no big gains from MMCSS. Thread that has been boosted with MMCSS should behave well, it shouldn't hog resources. Unfortunately I have already lsot the memory what the EVR presenter's scheduler thread does - but basicly a timing thread shouldn't have that many CPU cycles that it requires for it's work. Some CPU profiling with the EVR presenter side might give us clue where the CPU hogging happens - but I think it wont be worth for the MP1 anymore and MP2 will have completely rewritten EVR presenter code.
United Kingdom
- Thread starter
- #542
For reference, EVR presenter threads and priorities:
SchedulerThread() pulls samples off the internal queue and decides when to present/paint them - THREAD_PRIORITY_TIME_CRITICAL, MMCSS = not used.
WorkerThread() pulls samples from the EVR mixer and adds them to the internal queue - THREAD_PRIORITY_ABOVE_NORMAL, MMCSS = AVRT_PRIORITY_NORMAL, 'playback' class
TimerThread() is just a delay timer - THREAD_PRIORITY_BELOW_NORMAL, MMCSS = AVRT_PRIORITY_LOW, 'playback' class
It would be good for an ATOM/ION user to have play and see if the thread balancing could be improved for those systems.
Tony
I'm having a play with it at the minute but I'm off on hols for a week on Wednesday - I'll let you know if I can get a significant improvement, it's always useful having an under powered machine 
It's still better than the dev laptop which is out by over 3% at 50fps - it's closer to 52.
It's still better than the dev laptop which is out by over 3% at 50fps - it's closer to 52.One test would be to set all thread priorities to normal and then use MMCSS to boost all the three threads with
Code:
m_pAvSetMmThreadCharacteristicsW(L"Playback", &dwTaskIndex);
or
m_pAvSetMmThreadCharacteristicsW(L"Pro Audio", &dwTaskIndex);By the time I got two marked as playback the contention was killing Audio Renderer, managed to get the panic error message:
11-09-2010 22:22:40.214 [ 6c] dropping whole sample - late: 526.177 ms dur: 24.000 ms
11-09-2010 22:22:41.420 [ 6c] Dropped audio data detected: diff: 144.000 ms MAX_SAMPLE_TIME_ERROR: 1.000 ms
11-09-2010 22:22:41.421 [ 6c] dropping whole sample - late: 1609.920 ms dur: 24.000 ms
I think I need to work on the timing as that seems to offer more chance of dropping the contention for the ION and GMA500 I've got to test with. Actually I think the server has an HD3200 which are all the on or over the edge cards from the major manufacturers. I've been doing some profiling and there are more calls being made than I though there would be.
11-09-2010 22:22:40.214 [ 6c] dropping whole sample - late: 526.177 ms dur: 24.000 ms
11-09-2010 22:22:41.420 [ 6c] Dropped audio data detected: diff: 144.000 ms MAX_SAMPLE_TIME_ERROR: 1.000 ms
11-09-2010 22:22:41.421 [ 6c] dropping whole sample - late: 1609.920 ms dur: 24.000 ms
I think I need to work on the timing as that seems to offer more chance of dropping the contention for the ION and GMA500 I've got to test with. Actually I think the server has an HD3200 which are all the on or over the edge cards from the major manufacturers. I've been doing some profiling and there are more calls being made than I though there would be.
- Thread starter
- #546
I tried the "Pro Audio" class once - it's definitely in the "I'm having all the CPU resource I can get and I don't care about anyone else" category
Tony
I tried the "Pro Audio" class once - it's definitely in the "I'm having all the CPU resource I can get and I don't care about anyone else" category
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.
This is only showing that for some reason the audio decoding / rendering is not getting enough CPU resources. Nothing about a crash.
AW: MP1 EVR Presenter/dshowhelper community development
Do you have a new version to test? I detected that I still get randomly frame drops every 4000-5000 drawn frames (some times 2 frames are dropped at the same time). This happens only when watching TV (50 fps with DXVA running with 50 Hz) and while rewatching recorded TV with this high frame rates. Increasing the CPU priority to HIGH within Mediaportal seems to help a bit to increase the time span those hiccups occurs. That happens with and without the new audio renderer.
Do you have a new version to test? I detected that I still get randomly frame drops every 4000-5000 drawn frames (some times 2 frames are dropped at the same time). This happens only when watching TV (50 fps with DXVA running with 50 Hz) and while rewatching recorded TV with this high frame rates. Increasing the CPU priority to HIGH within Mediaportal seems to help a bit to increase the time span those hiccups occurs. That happens with and without the new audio renderer.
Re: AW: MP1 EVR Presenter/dshowhelper community development
Please let DPC Latency Checker run for 10 minutes and then check if there are any big spikes - DPC Latency Checker - both with playing video and not playing.
Please let DPC Latency Checker run for 10 minutes and then check if there are any big spikes - DPC Latency Checker - both with playing video and not playing.