Yes, you can get that performance if you talk to the hardware directly - which
is what all the games programmers were doing, of course (for whom DirectX was
primarily developed). DOS is also vehemently single-tasking. I suppose even on
unix you could get some sort of performance boost by bypassing the kernel and
talking directly to the hard disks, audio hardware, etc - but it wouldn't really
be unix any more! CDP did this on the Atari XT - by talking directly to the hard
disk, and to the cartridge port, we were able to get full CD-guality stereo i/o
on an 8MHz cpu. 

If there's a fault, its in us demanding a (pre-emptive) multi-tasking system
with single-tasking performance, and Microsoft and Intel betweeen them trying to
square the circle on our behalf. The NeXT machine ran a form of Unix, but
included a 56K dsp chip on whch most of the audio processing was intended to
run. The Apple is co-operatively multi-tasking, and therefore offers theoretical
advantages for audio; but it's expansion capacity is relatively limited, and the
internal audio circuitry is not ~that~ good, and the API's are not ~that~ good.
Hence Pro-tools. Hence the Kyma system, etc, etc, etc.

What is happening now is that, for time-critical tasks such as audio (and as has
already happened with graphics, to a great extent), audio processing is being
transferred from the host PC to single-tasking dsp-intensive soundcards (e.g the
Extended Csound card, the Yamaha mixer card, or the 15 sharcs in the forthcoming
Creamware SCOPE system). The latency on such devices will be down to the sample,
and the bandwidth very high, - but you will need to use the Creamware API's and
drivers which talk directly to the card to take advantage of it - or buy the
third-party software that uses them. The Microsoft API's are an expressly
base-level framework which all soundcard devleopers are invited to support, so
that a minimum level of performance is guaranteed across the whole PC diaspora.

Musicians are now asking almost absurd things of a general-purpose computer -
real-time processing and mixing of 32 channels of 48KZ  16bit audio, all while
updating increasingly luxuriant displays all designed to create the illusion
that somehow you are not using a 'computer' but a real hardware synth or mixer -
while sending your email, printing your letters, and playing DOOM. To me, it is
extraordinary it can be managed at all. And if it can't do it, we blame everyone
and everything except our own ambitions, which are always entirely reasonable,
of course!



Richard Dobson



Eli Brandt wrote:
> 
> Richard Dobson wrote:
> > It is also sometimes forgotten that that the PC was, and still is,
> > primarily a general-purpose computer (albeit highly expandable and
> > customizable); such a machine will probably ~always~ have limitations
> > when being pushed to do zero-latency audio. That is not Microsoft's
> > fault either.
> 
> I have to defend the PC here: the hardware is not the problem.  Bare,
> its interrupt latency is well down in the microsecond range.  Even
> DMA-based sound cards can reasonably work with blocks of a millisecond
> or so, not to mention the modern cards.
> 
> And under DOS (including Windows 3.1) you can actually get that kind

Richard Dobson wrote:
> If there's a fault, its in us demanding a (pre-emptive) multi-tasking
> system with single-tasking performance, and Microsoft and Intel
> betweeen them trying to square the circle on our behalf.

But a multi-tasking OS with real-time performance is no squared circle.
I'd hesitate to call it a solved problem, but it's a known area of OS
design.  Some commercial Unix vendors manage it -- not RTOSes suitable
for driving an X-29, but good enough for us.

Under Irix 6.4, for example, I can get 7-ms audio output latency;
probably better if I figured out how to use processor affinities right.
The audio API is capable and clean.  And MIDI is timestamped for a
change, which cuts way down on timing jitter.  This system's designers
deserve recognition of their work.

> Musicians are now asking almost absurd things of a general-purpose computer -
> real-time processing and mixing of 32 channels of 48KZ  16bit audio, all
> while updating increasingly luxuriant displays [...]
> To me, it is extraordinary it can be managed at all.

I am duly impressed by the ever-increasing throughput that the hardware
permits.  I am less enamored of the stubborn latency that the OS imposes.
(It's only fair to point out, though, that W98 has noticeably lower
user-mode scheduling latency than W95.)  By no means do I expect proper
real-time design to come gratis on a silver platter, but I think it
useful to be clear where the work would need to be done.

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/










Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13526;
          24 Jul 98 17:43 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa20288;
          24 Jul 98 17:43 BST
Received: (qmail 6937 invoked from network); 24 Jul 1998 16:43:03 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 24 Jul 1998 16:43:03 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (RAA23097); Fri, 24 Jul 1998 17:39:31 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 24 Jul 1998 17:39:20 +0100
Received: from nmol.com [206.162.11.2] by hermes via SMTP (RAA02853); Fri, 24 Jul 1998 17:39:19 +0100 (BST)
X-ROUTED: Fri, 24 Jul 1998 10:50:54 -0600
X-TCP-IDENTITY: Mikeb
Received: from nmol.com [206.162.11.170] by nmol.com with smtp
	id AKDCANAC ; Fri, 24 Jul 1998 10:50:12 -0600
Message-ID: <35B8BA0E.D14E1BC9@nmol.com>
Date: Fri, 24 Jul 1998 10:45:05 -0600
From: Mike Berry 
X-Mailer: Mozilla 4.05 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Csound mailing list 
Subject: Re: MIDI input
References: <199807241415.PAA17360@hermes>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

I wanted to point out here that in OS 8.1 Apple has reduced the sound output
latency in the MacOS to 11.6 ms (512 sample frames) from 25 ms (probably due
to the many cries over the years by RT audio developers).  When combined with
the cooperative multi-tasking which allows us audio developers to hog the
entire CPU, the MacOS makes a nice balance between UI and performance.
-- 
Mike Berry
mikeb@nmol.com
http://www.nmol.com/users/mikeb












Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14230;
          24 Jul 98 22:49 BST
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa16464;
          24 Jul 98 22:49 BST
Received: (qmail 837 invoked from network); 24 Jul 1998 21:49:43 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by mercury.bath.ac.uk with SMTP; 24 Jul 1998 21:49:43 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (WAA25898); Fri, 24 Jul 1998 22:47:28 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 24 Jul 1998 22:47:18 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (WAA05724); Fri, 24 Jul 1998 22:47:18 +0100 (BST)
Received: (qmail 17037 invoked from network); 24 Jul 1998 21:47:12 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.52)
  by jaguars with SMTP; 24 Jul 1998 21:47:12 -0000
Message-ID: <35B8FF46.93FEDB65@cableinet.co.uk>
Date: Fri, 24 Jul 1998 22:40:22 +0100
From: Richard Dobson 
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Csound mailing list 
Subject: Re: MIDI input
References: <199807241415.PAA17360@hermes> <35B8BA0E.D14E1BC9@nmol.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Yes, I remember reading about this a while back (I think on the music-dsp list).
The need to buffer audio this way must remain the final stumbling-block to
getting i/o latency down to the sample. The PC has been saddled with its history
of Adlib and Soundblaster cards, all using slow DMA channels which  don't work
properly with small buffers. I know that in principle DirectX is trying to
achieve this, by reading and writing directly to the same buffer used by the a/d
and d/a converters; though there still appears to be a residual latency, about
which I don't have any detailed information.

Is that low latency strictly using the PPCs internal audio hardware, or can it
be achieved with PCI-based cards too? 

Richard Dobson


Mike Berry wrote:
> 
> I wanted to point out here that in OS 8.1 Apple has reduced the sound output
> latency in the MacOS to 11.6 ms (512 sample frames) from 25 ms (probably due
> to the many cries over the years by RT audio developers).  When combined with
> the cooperative multi-tasking which allows us audio developers to hog the
> entire CPU, the MacOS makes a nice balance between UI and performance.
> --
> Mike Berry
> mikeb@nmol.com
> http://www.nmol.com/users/mikeb










Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14275;
          24 Jul 98 23:14 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa17937;
          24 Jul 98 23:14 BST
Received: (qmail 18299 invoked from network); 24 Jul 1998 22:14:24 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 24 Jul 1998 22:14:24 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (XAA13009); Fri, 24 Jul 1998 23:12:09 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 24 Jul 1998 23:11:54 +0100
Received: from jaguars-int.cableinet.net [193.38.113.9] by hermes via SMTP (XAA12792); Fri, 24 Jul 1998 23:11:53 +0100 (BST)
Received: (qmail 18094 invoked from network); 24 Jul 1998 22:11:47 -0000
Received: from unknown (HELO cableinet.co.uk) (194.117.146.52)
  by jaguars with SMTP; 24 Jul 1998 22:11:47 -0000
Message-ID: <35B9050A.CC5A9D58@cableinet.co.uk>
Date: Fri, 24 Jul 1998 23:04:58 +0100
From: Richard Dobson 
Organization: Composers Desktop project
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Csound mailing list 
Subject: Re: MIDI input
References: <199807232326.AAA18602@hermes> <35B853E5.62BA1FFA@cableinet.co.uk> <35B864B8.24E28006@qsure.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

Well, not a lot! The mouse interrupt, and a few gui updates. The 68000 was/is a
really good CPU (flat memory model, 32bit registers - and plenty of them), with
a nice instruction set (I have always been a fan of Motorola chips). From the
same C code, Atari executables come out easily half the size of the DOS-486
equivalents. The Atari (now Steinberg) Falcon is still widely used for audio
work - it has a Motorola 56K dsp inside it - a pretty powerful piece of
hardware, despite some very idiosyncratic design decisions. I gather it is still
very popular in Europe.

Trouble is, once I had discovered Visual C++, I never really wanted to go back
to Lattice on the Atari!

Richard Dobson

Ben Jefferys wrote:
> 
> Richard Dobson wrote:
> 
> > CDP did this on the Atari XT - by talking directly to the hard
> > disk, and to the cartridge port, we were able to get full CD-guality stereo i/o
> > on an 8MHz cpu.
> 
> !! Cool. What else was that CPU doing at the same time? ;)
> 
>










Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa14675;
          25 Jul 98 5:35 BST
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa09721;
          25 Jul 98 5:35 BST
Received: (qmail 25865 invoked from network); 25 Jul 1998 04:35:05 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
  by pat.bath.ac.uk with SMTP; 25 Jul 1998 04:35:05 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (FAA15576); Sat, 25 Jul 1998 05:32:26 +0100 (BST)
Received: from exeter.ac.uk by maths.ex.ac.uk; Sat, 25 Jul 1998 05:32:16 +0100
Received: from out2.ibm.net [165.87.194.229] by hermes via ESMTP (FAA04914); Sat, 25 Jul 1998 05:32:15 +0100 (BST)
Received: from ibm.net (slip129-37-49-76.dc.us.ibm.net [129.37.49.76]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id EAA82390 for ; Sat, 25 Jul 1998 04:32:13 GMT
Message-ID: <35B960C9.3D8E0637@ibm.net>
Date: Sat, 25 Jul 1998 00:36:25 -0400
From: Job van Zuijlen 
Reply-To: zuijlen@ibm.net
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: Csound List 
Subject: Re: [?] Higer order Butterworth filter
References: <35B6A5FA.F5D7BF54@ibm.net> <199807242000.WAA18612@piraya.electrum.kth.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk

In response to my remark about the need of feedback in higher
order filters,
Magnus Danielson wrote:
> But, this feedback hardly renders a Butterworth filter.

I stand corrected.  I wrote a little bit in haste, and it has been a 
long time ago since I dealt with filters (I still owe the Csound
community an introduction of myself).  I was also wrong about
cascading filters.  I was thinking of cascading a series of
filters that are exactly the same, but that is of course not how
it is done.  

In the meantime I found yet another useful book (which I
actually have in my collection):

   "Elements of Computer Music" by F. Richard Moore (Prentice Hall,
   1990)

It includes a section (Sec 2.4) about digital filters with a 
C program to calculate poles and zeros.

I must say I rather enjoy these discussions, and I don't think this
list is sleepy at all, David!

Job van Zuijlen