DN> I would think the simplest approach would be for the timing to be
 DN> internal to the VDM.

        That was my feeling, as well, but I wanted your slant on it.

 DN> Providing the DOS program yields its timeslices
 DN> when its polling fails, thus keeping the OS/2 program active, there

        Well, not real gracefully, but well enough.  I haven't had any
problems with the sound crashing, unless I try to open up stuff on the
desktop, but then it does that even without the VDM (I'm running 41,000
samples per sec by 2 channels by 16 bits per channel).

 DN> should be no contention for the CPU and so timer events should be quite
 DN> punctual. A granularity of 100 msec should be easily achieved, since
 DN> that is 3 whole timeslices and a little more too.

        I havenm't had any problems with that, either, or at least not ones
not related to my coding (It seems I can't add, you see...).

 DN> Well, I've had to resort to a little bit of assembler, since the
 DN> semaphore API's seem to need 32-bit registers and 16-bit compilers
 DN> won't always generate such code. I need to contact IBM via Compuserve
 DN> to make sure I'm using the right calling sequence for the semaphore
 DN> stuff, but we are progressing.

        This shouldn't presnt a problem.  Inline assembler is SOP, and
since all I want to do is call the assembler routine, wait for the
semaphore, and then exit the assembler (no parms passed either way), it
should be a piece of cake.  Drop a line if you need info, or if this is
starting to take enough time (don't be shy) to require some recompensation.

                                                        Les

e-mail: lrhorer{at}fibrcom.com

--- EZPoint V2.2