From: rossb <rossb@0f58301d-fd10-0410-b4af-bbb618454e57>
Date: Wed, 11 May 2011 21:05:18 +0000 (+0000)
Subject: extra comments
X-Git-Tag: pa_stable_v19_20111121_r1788~78
X-Git-Url: https://andrewgundersen.net/repos?a=commitdiff_plain;h=5716669053ba122be08573721cb27c968da9ca18;p=portaudio

extra comments
---

diff --git a/src/hostapi/dsound/pa_win_ds.c b/src/hostapi/dsound/pa_win_ds.c
index f25ede7..5a7fee3 100644
--- a/src/hostapi/dsound/pa_win_ds.c
+++ b/src/hostapi/dsound/pa_win_ds.c
@@ -2784,6 +2784,11 @@ static PaError StartStream( PaStream *s )
         timerResolution = msecPerWakeup/4;
 
         /* set windows scheduler granularity only as fine as needed, no finer */
+        /* Although this is not fully documented by MS, it appears that
+           timeBeginPeriod() affects the scheduling granulatity of all timers
+           including Waitable Timer Objects. So we always call timeBeginPeriod, whether
+           we're using an MM timer callback via timeSetEvent or not.
+        */
         assert( stream->systemTimerResolutionPeriodMs == 0 );
         if( timeGetDevCaps( &timecaps, sizeof(TIMECAPS) == MMSYSERR_NOERROR && timecaps.wPeriodMin > 0 ) )
         {
@@ -2798,6 +2803,10 @@ static PaError StartStream( PaStream *s )
 
 #ifdef PA_WIN_DS_USE_WMME_TIMER
         /* Create timer that will wake us up so we can fill the DSound buffer. */
+        /* We have deprecated timeSetEvent because all MM timer callbacks
+           are serialised onto a single thread. Which creates problems with multiple
+           PA streams, or when also using timers for other time critical tasks
+        */
         stream->timerID = timeSetEvent( msecPerWakeup, timerResolution, (LPTIMECALLBACK) TimerCallback,
                                              (DWORD_PTR) stream, TIME_PERIODIC | TIME_KILL_SYNCHRONOUS );