MIDI Timing and PC soundcards

[List, Christopher]

Just wanted to add my two cents here (having written a Win95 MIDI
sequencer myself) - this is by no means a sales pitch or flame, just a
clarification for anyone who might be curious and/or confused and/or
saying to themselves "I thought my Win95 sequencer was working fine all
along, maybe it's not!"

Mikko's is the most accurate description I've read so far of windows
timing issues. The point that I think most people have missed is that
Windows ***doesn't want*** you to have low level control of the machine
- for security and stability reasons. That's why an OS like WinNT
doesn't allow the kind of 16-bit processes that Win95 does - because
WinNT is more secure. WinNT is more "strict" in it's multi-tasking, and
it handles 16bit code differently from Win95, and is not very good for
sequencing. 

Novice windows sequencer programmers will get put off because they'll
try to use the stock 32-bit timer APIs for sequencing under Win95 - and
that won't work, you get multitasking interupts and bad timing. 
There are two other options (under Win95); 
1. Use an old compiler (like MSVC 1.5) and write everything as Win3.1
software.
2. Write your front-end in a new 32-bit compiler, and write all your
time-sensitive MIDI stuff in a 16bit DLL written in an older compiler.
This second option is called "thunking" and is obviously more
complicated and more work, but it's really not that bad once you get
everything set up. There's a slight overhead for calls between the 32bit
and the 16-bit side, but those calls ( to add and change events, start
and stop, etc) are a tiny fraction of the main processing of any
sequencer - which is the playback loop - and the playback loop lives
entirely on the 16-bit side, sending queued messages over to the 32-bit
side just to tell it to update the GUI.

A 16-bit DLL (or a full 16-bit program) under Win95, can totally take
control of the machine and not allow any other processes to interupt it.
I've had it happen when I've had bugs in my 16-bit timer code :) - no
Ctrl-Alt-Del here! - no choice but the reset button! In my experience, a
sequencer under Win-95 that uses a 16-bit DLL (and they all do) has no
problem with 1ms resolution on a 60Mhz Pentium. - You can open and close
windows, write to files, whatever - but if your MIDI is pumping out,
everything else will wait for it, and on a slow machine, all that other
stuff will get really slow. That's my experience anyway, and I've done a
good deal of testing. Mind you, I haven't done that with a "production"
sequencer that was written in the past two years that does audio
playback and all this other processor-intensive mumbo-jumbo. This
experience is with Cakewalk 3.0 and my own software.

You basically can't write a Win95 sequencer w/o an old Win3.1 compiler
for the 16-bit code. I suppose you could write a vxd to do something
similar, and it might make your life easier in the long run, but it's
really not necessary, and the thunking thing works.

I don't know much about sending and receiving serial port data, but I'd
be curious to see if you could avoid that latency by accessing the
serial port from a 16bit DLL, or if a VxD is your only way to go. MIDI
devices that attach to the serial and parallel ports use a VxD and
definitely don't use message queues. I always thought the problem with
serial port MIDI devices was the speed of the serial port - being only
about 112k baud - most manufacturers of both serial and parallel port
MIDI interfaces (e.g. Key Electronics) admit that the parallel port
models have better timing...   ...but I'm no hardware guy...

As Mikko mentioned, as of version5, there are no DirectX extentions for
Midi or (much more importantly) Multimedia Timer functions.

I haven't tried Win98 yet, but I would imagine it's all the same -
except that you have to have your MIDI data relayed to you through a
browser via a special Internet channel from MSN.COM :) :)

Lastly all the 16bit / 32-bit stuff implies that any software that will
run tight under Win3.1 will work exactly the same under 95 - as the
Win3.1 programs are all 16-bit.

- Just wanted to clear that up. In short, I'd say if you have a PC with
Win95 and a cheap soundcard with a MIDI port, get some cheap (or
freeware / shareware) sequecing software and see for yourself.

Anybody worked with QNX?

- CList


> -----Original Message-----
> From:	Mikko Helin [SMTP:MHELIN at tne01.ntc.nokia.com]
> Sent:	Tuesday, October 13, 1998 8:36 AM
> To:	synth-diy at mailhost.bpa.nl
> Cc:	MHELIN at tne01.ntc.nokia.com
> Subject:	RE: MIDI Timing and PC soundcards
> 
> I once programmed a MIDI sequencer for DOS with Borland C on a PC with
> 8 MHz V20 (8088 clone), and there were no problems with timing,
> even with my modified RS-232 (8250 chip) port MIDI interface. But 
> Windows is another story (hope someone developed a nice GUI on top
> of DOS with some device driver standard like in Linux). Anyway, the
> biggest
> problem with Windows isn't interrupt response time, but the difficulty
> in writing VxD's (the "DOS" part of device drivers, which handles
> interrupts and other realtime tasks). DirectX is good for audio,
> it decreases latency quite a lot, but there are no DirectX services
> for MIDI input or timer routines. For Window 95/98 all "realtime"
> applications should also use 16 bit code, which is faster than
> 32 bit one, not executing faster but switching tasks (which isn't
> done when 16-bit code is run, I mean that 16-bit apps don't
> share runtime with each other, but they do so with 32 bit apps 
> running in background). This is usually done by calling routines 
> in 16-bit DLL's from the 32-bit code. There are some realtime
> expansions for Windows, which are practically VxD's that take
> all control of the computer. 
> 
> -Btw. The Windows 98 DDK is free, you don't have to pay the MSDN
> subscrition payments for it, see 
> 
>  http://www.microsoft.com/hwdev/ddk/ddk98.htm
> 
> Needs though Visual C++ 5.0 and Windows 98 or NT 4.0.
> 
> -Mikko  
> 
> Karl H.:
> >
> >The result : The PC I tested on ('486, but I don't think a Pentium
> would
> >make very much difference) would not respond faster than 50ms to
> incoming
> >serial data. Also the time used was very erratic, varying from 50ms
> to
> >150ms. This is a LONG time! The variations did not seem to be very
> >dependant on processor load.
> >
> >The culpit is Windows, which puts the information in a message queue,
> >instead of calling my message handler directly.
> >