3

In our C# .NET application we have two DirectShow filter graphs each showing a video device and one audio device. Whenever the filtergraphs are running the system time is slowed down about 4-6s per minute... The graphs are not encoding anything, just displaying what comes in from the sources.

This just happens in the application and not in GraphEdit.

What could cause such a behavior? and what could we do against it?

hanneswurstes
  • 273
  • 3
  • 9
  • Pretty unlikely that it actually affects the system clock. Don't count on timers that you set for, say, one second to fire *exactly* after one second. It always takes more, longer if your program is especially busy. – Hans Passant Jun 15 '11 at 13:25
  • the problem appears on the Windows clock (the one visible in the task bar) as well.. and besides this it also affects the DirectShow graph clock - that leads to mediafiles with a wrong timing when capturing a video. – hanneswurstes Jun 15 '11 at 14:23

2 Answers2

6

I think this must be a bug in one of the drivers, causing it to hold off interrupts long enough and often enough for some timer interrupts to be dropped. Nothing else in DirectShow would be able to affect the system clock like this.

G

Geraint Davies
  • 2,847
  • 15
  • 9
  • this seems to be the closest answer, although we just use stock windows drivers which should know about correct interrupt handling... – hanneswurstes Jun 21 '11 at 08:45
  • 1
    DirectShow switches the interrupt frequency for the clock to about 10x the normal interrupt rate (or at least used to). I imagine that this could easily show up problems that are not apparent when the clock interrupt rate is lower. – Geraint Davies Jun 21 '11 at 12:20
0

Are you running your application on a virtual machine? I once had a similar problem (altought not with DirectShow) and after much digging we found out the problem was related to virtual machines - which time can slow down under certain circumstances.

Benoittr
  • 4,091
  • 4
  • 27
  • 38