[gmpi] Re: Reqs 5, 6, 11 for debate

On Friday 21 November 2003 17.09, RonKuper@xxxxxxxxxxxx wrote:
> Under Linux (and presumably OSX) you can just say "all future momory I
> allocate from here should be page locked by default". Thus is becomes the
> hosts responsibility, and the plugin doesnt have to care.
> <<<
>
> That's great for Linux, but today no such API exists in the Windows OS.  So
> if I write a GMPI plugin today for Windows XP, I'll have to change it to
> run on Longhorn, and then after my changes this plugin will break under XP
> unless I do a platform check to see if the API that I need is available.
> One goal of this is to not have to do platform checks in the plugin.
>

Well there exist something similar SetWorkingSetSize but since programs
started to overuse it (I have seen calls to it from notepad...) I guess
Microsoft had to start ignore it - correct?

AllocateUserPhysicalPages can be found at, but then you would have to copy 
stack and executable to the allocated area - not easy...
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/allocateuserphysicalpages.asp>

Found this at
   http://www.iseran.com/Win32/CodeForSpeed/special.html

-----------------------------------
Real Time Programming


Desktop versions of Windows are not real time systems. The closest you can get 
is a VxD in Win9x. Even NT drivers have a variable delay between when an IRQ 
gets signalled and the driver gets to do some work in the corresponding 
Deferred Procedure Call. If things are bad for drivers, things are worse for 
user mode code. 

1. You can make a process real time and then vary the priorities of threads 
within. You can not have one real time thread inside a normal priority 
process, which is a pity. 

2. Don't use SetWorkingSetSize() -it doesn't really lock memory down, it just 
makes things painful that can't cope with an app that thinks it knows better. 
Win2K's AllocateUserPhysicalPages() may be viable, but still tread carefully. 

3. Design the system expecting at least 2 ms lag between an external event and 
your RT thread hearing about it.  

4. NT timeslices are 10-15 mS unless changed; Win9x is 55mS. 

5. Don't attempt to run the soft real time Win32 code on Win9x or performance 
will be dire. Some people may attempt to do this even if the documents tell 
them not to, which leads to complications, especially if they are in 
marketing. A test and a dialog box warning saying 'proceed at your own risk 
this is untested and unsupported' is a good escape route here.

That last item is important, believe me. You spend months getting something 
just about working in NT and then someone thinks if it's a win32 app it must 
run under Win95 too. 


The trick with soft real time apps is to determine what is important, and 
devise an algorithm to work around it. For example, early DVD playback apps 
used to drop frames when they were getting behind, but well written DirectX 
Media apps now signal their performance problems upstream, so the renderer 
just degrades resolution slightly but the frame rate can stay constant. Maybe 
your problem has a similar solution. 


-- 
Roger Larsson
Skellefteå
Sweden

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: