directshow - Behavior of DirectSound audio renderer with the reference clock -


i'm working on source filter feeds video/audio captured our software through directshow graph. got video working relatively painlessly, trying add audio output pin proving quite challenge. specific question have is: audio renderer modify actual reference clock playing sound?

i'm seeing jerky video playback. attached below chunk of log file, , looks once in while reference clock "stops" while system time keeps ticking. make sense?

one thing should mention audio samples u-law 8 khz 8-bit , each packet 120 ms. here's complication: when receive audio data network, doesn't come time information, our software assigns sample timestamp @ time packet received. video samples stamped original source, accurate. if ignore audio sample times , assign sample timestamps 120 ms apart, video play smoothly. problem i'm still not understanding complete relationship between reference clock , audio/video renderers , puzzles me have similar source filter plays same data without jerking video (it doesn't have logging, , didn't chance add see if reference clock modified in case).

this piece of log:

sys clock    (delta)  streamtime  (delta)   drift between clocks: ------------------------------------------------------------------ 15:54:40.755 (0.005)  1.838       (0.005)   0.000 15:54:40.761 (0.006)  1.844       (0.006)   0.000 15:54:40.889 (0.128)  1.972       (0.128)   0.000 15:54:40.894 (0.005)  1.977       (0.005)   0.000 15:54:40.899 (0.005)  1.982       (0.005)   0.000 15:54:40.903 (0.004)  1.986       (0.004)   0.000 15:54:40.931 (0.028)  2.014       (0.028)   0.000 15:54:40.936 (0.005)  2.019       (0.005)   0.000 15:54:41.019 (0.083)  2.080       (0.061)   0.022 15:54:41.175 (0.156)  2.080       (0.000)   0.178 15:54:41.181 (0.006)  2.080       (0.000)   0.184 15:54:41.190 (0.009)  2.080       (0.000)   0.193 15:54:41.197 (0.007)  2.080       (0.000)   0.200 15:54:41.202 (0.005)  2.080       (0.000)   0.205 15:54:41.210 (0.008)  2.080       (0.000)   0.213 15:54:41.216 (0.006)  2.080       (0.000)   0.219 15:54:41.220 (0.004)  2.080       (0.000)   0.223 15:54:41.313 (0.093)  2.080       (0.000)   0.316 15:54:41.317 (0.004)  2.080       (0.000)   0.320 15:54:41.408 (0.091)  2.116       (0.036)   0.375 15:54:41.412 (0.004)  2.120       (0.004)   0.375 15:54:41.432 (0.020)  2.140       (0.020)   0.375 15:54:41.436 (0.004)  2.144       (0.004)   0.375 15:54:41.439 (0.003)  2.147       (0.003)   0.375 

when sound card in graph selected reference clock. other filters, including video renderer, use determine when show samples. using system clock in parallel not idea; should use same reference clock in sync.

if know real length of audio samples, , you're sure don't lose of them (for example, use tcp, not udp) assigning sequential 120 ms time intervals solution. taking timestamps system clock when sample arrives network bad idea because introduce random time shifts caused network behavior - never know how long take network packet come.

if have 2 filters , want see how timing different can install grapheditplus, insert sample grabber before/after filters, right click , select "watch grabbed samples". show timestamps , other information. also, can right click graph window , choose "see event log". can help.


Comments

Popular posts from this blog

ASP.NET/SQL find the element ID and update database -

jquery - appear modal windows bottom -

c++ - Compiling static TagLib 1.6.3 libraries for Windows -