MIDI Timing and PC soundcards

[McIntosh, Malcolm]

Magnus,

What operating system would you suggest one use?  OS/2 Warp, Be
(http://www.be.com/), LINUX, Macintosh or something else?  I am currently on
OS/2 Warp 4, but I am having trouble finding a soundcard.

Malcolm

(P.S. I have been quiet because I have no time to finish the projects I have
half done!)
(P.S.S  Thanks for the card Hans!)


> -----Original Message-----
> From:	Magnus Danielson [SMTP:magnus at analogue.org]
> Sent:	Monday, October 12, 1998 1:02 PM
> To:	b.layer at vikingelectronics.com
> Cc:	synth-diy at mailhost.bpa.nl
> Subject:	Re: MIDI Timing and PC soundcards
> 
> >>>>> "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