MIDI Timing and PC soundcards

[Magnus Danielson]

>>>>> "BL" == Bill Layer <b.layer at vikingelectronics.com> writes:

 BL> Hi All,
 BL> A question for the knowledgeable.

Do you count me in?

People!
Sorry for this long reply...

 BL> I'm just beginning to get into PC based MIDI sequencing, and I'm a little
 BL> confised about all the talk about timing, and how 'dreadful' a PC is at this.

 BL> What exactly is the issue here? How could anything as fast as even a
 BL> 486DX33 be SLOW enough as to not keep up with the pace of MIDI data? Isn't
 BL> the processor magnatudes faster than the requirements of the MIDI data stream?

You are correct!

A 486DX33 is blitzing fast as compared to MIDI!

People have successfully been doing MIDI with all kinds of 8-bit CPUs
for ages (8051, Z80, 6502 et.al.), infact the buissness is very locked
on target on smaller CPUs for some reason.

On the same time, a 486DX33 isn't enougth to run the applications!

Now, there is a few issues here which display some well known problems
in operating system design which still ceases to reach to this kind of
people.

Many of the stone-ages operating systems that people are used to see
(we talk about DOS and Windows-95) is designed to work with only one
program running at any time, that means giving the full CPU time to
anything currently runnig. This is good for batch-job running and
similar kind of jobs. However, it is inadequate for many of the
day-to-day realtime issues.

Realtime is a term used to note that there is some sort of real time
aspects to a problem. This means that the program/hardware must
respond within some timelimit in order to keep up with the real time
outside the computer. Whenever you put real-time demands on something
you usually overturn a number of assumptions that where rock-solid
truths up to that point.

For a very simple application you can guarantee real-time asspects by
having the CPU doing nothing most of the time and when at need you go
and do the necessary task (which only consumes say 10 ms of each 100
ms frame). For so called single-process systems (which many systems
are) this will work just fine, except maybe that you overdimensioned
the CPU speed by a grade of 10, we have 90% idle-time.

But now someone comes along and say "Hey, this CPU has only 10%
utilisation!". While this is correct it may not be correct to fill it
up with 90% more of CPU load. It is very safe to let the CPU do more
on each turn, as long as the load doesn't increase over 100%.
But someone now wants the CPU to perform many other tasks, such as
responding to user demands (like moving the Window). Suddenly has the
system become a multi-process system.

In multiprocess systems you share the CPU time among the processes by
the use of a scheduler (which makes up a schedule after which the
processes is being executed after). Classical UNIX schedulers as well
as most others will try to share the time equally on some sort of
fairness, which is not a easy task since the scheduler does not really
have a clue what is the need of either the application or the
user. Very vauge hints is usually at hand. Instead, the scheduler will
look at how much time the application spends. The operating system
kernel fall into it's own scheduling domain, taking it's time as it
needs it.

A way to have actions happening on need is interrupts, either an
interrupt is issued by the hardware needing serivce (the harddisk has
finally found that 1kB block I asked for) or due to a hardware timer
timed out. The interrupt is thus a way to interrupt normal execution,
save away what is needed for later return to track and execute the
necessary interrupt routine that will do the task needed. The
interrupts thus have an overhead.

While interrupts are very nice and can (fairly) quickly take that
little time which was needed for a simple task (like handle MIDI input
and output) things is slowly getting a bit messier. Now you have
multiple user applications running concurrently, multiple kernel task
occur concurrently and together with this a number of interrupts that
can fire of at virtually any time. Also, when multiple interrupts
occur at the same time, you need to prioritize which of them is most
time critical. Yeat again, if an interrupt occur while another is
executing it may need to wait very long before you can get to do
something.

Also, now that you have multiple processes/tasks/threads happening all
over, and they are communicating with each other you also needs to
consider which task is modifying which data at what time. Say that you
need to update two datafields to read of something from your MIDI
queue without corrupting the datastructure, how can you be sure that
your MIDI card doesn't issue an interrupt just between those
modifications and goes about and uses this temporary illegal state to
add something to the queue?
You need some sort of locking scheme to keep sensitive operations
atomic, the semafor scheme being used will thus syncronise these
otherwise asyncronious tasks.

Dont ask about multiple processors!

This is a virtual mess and this is what our poor OS hackers have to
figure out ways to handle. The thing is, if you want to achieve
similar results you will not only need to hang into the OS well, you
need to understand these basic issues.

So, my bottom line with this very long post is that the processor may
be blitzing fast compared to the simple problem, but unless you
understand the full width of how things interact in a complexer
solution you will loose big.

This is how MIDI software lags, how virtual analogs in many cases
either drops audio every now and then or lags heavilly.

A modern operating system can (when properly programmed) deal with all
these things. With this in retrospect I can add that I don't consider
Windows (any taste) as being a suitable OS. Partly due to the lack of
propper features and partly due to the lack of possibility for propper
deep-within understanding of what the OS is doing. Microsoft does not
allow this and therefore they will not see good realtime stuff occur,
they will all have a unstableness over them.

Now, people... go figuring on the number of CPUs in a Fairlight CMI or
Lexicon 480L or why not the little brother LXP-5???

Cheers,
Magnus