LR>  DN> I think the problem is that he has no buffer space for sending
 LR>  DN> messages, only for receiving.
 LR>
 LR>         That's odd.  I wonder why he set it up that way.  I
 LR> can see how this could possibly be a problem, but then why
 LR> does it work on his machine, and not mine?

 DN> Hi Les,

 DN> Does he have some networking software that offers "value
added" pipe
 DN> support? Something along those lines might provide buffers where
 DN> vanilla OS/2 doesn't.

        Sorrry to be so long getting back.  I've been running at 110% here
for the last couple of months.  The answer is, I really don't know, and the
original author has removed OS/2 from his system.  :-(

        However, he's given me the source code with all rights for my own use. 
 I believe you had made an offer of assistance a while back.  Is that still open?

        I could send you the source, no worries.  I do also have Borland
C++, and porting might be little trouble, allowing me to do much of the
debugging and testing.  The author said his last compile was under Visual
Age C++.

 LR> required.  At the moment, I simply use trial and error and
 LR> a hand-set delay to have the apps start simultaneously.  

 DN> There is, I believe, a DOS interrupt available in a VDM that can
 DN> access an event semaphore created by an OS/2 process. [I don't have my
 DN> copy of Ralf Brown's list handy.] This would have much less latency for
 DN> synching DOS and OS/2 processes than a named pipe transmission.

        This sounds *VERY* interesting.  Any further info?  Would it be
difficult to implement?  Again, all I need is to start the timer going in
the VDM based upon the starting point of the OS/2 .WAV process.  An
accuracy of +/- 50ms is desired.  Latency between the processes is no big
deal, since the communications is only one-way, as long as it is quite
uniform.  Any large variation in the latency would be a killer, though.

        At a more advanced stage, re-synchronization will be a definite
plus, as will getting the OS/2 process to start at a given time after the
start of the audio.  IOW, for editing purposes, it would be *VERY*
advantageous to be able to start and synch the OS/2 and DOS processes at,
say, 18 minutes 10.4 seconds into their respective files.

 LR> The long term answer may be to incorporate both codes into
 LR> a single code under a single compiler, and use directly

 DN> This would be the ideal solution. The event semaphores would simply
 DN> operate across threads.

        Right.  Unfortunately, I don't have the time just now to port the
DOS code, which is moderately extensive.

 LR> interim measure, I may have the music code write to I/O
 LR> ports, which should be faster and more uniform than named
 LR> pipes.

 DN> Device driver calls are preferable to hitting I/O ports, since you
 DN> don't need to poll.

        I have to poll, anyway.  The DOS code simply waits for the
semaphore (in whatever fashion) to come across before continuing.

 DN> Let the IRQ do the work for you. It also doesn't
 DN> need IOPL-enabled code. [Ugly 16-bit stuff.]

        Well, the DOS interrupt / OS/2 semaphore scenario may be the
ticket.  I'll let you take a look at the source code, and see what you
think.  I can also send you my source code, if you think it will help, or
just my executable code, if that would help.


        Do you have access to Internet e-mail?  If so, what's your e-mail
address?  If not, can you receive Netmail / F'ATTCH's at the above FIDO
address?  I could re-compile my nodelist to include Zone 2, if necessary.

                                                        Les

 
 e-mail: lrhorer{at}fibrcom.com
 
 --- EZPoint V2.2