From alsa-devel-owner@alsa.jcu.cz  Thu Feb 11 02:21:24 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id CAA23280
	for <alsa-devel@alsa.jcu.cz>; Thu, 11 Feb 1999 02:21:18 +0100
Received: from someip.ppp.op.net (d-bm2-0c.ppp.op.net [209.152.194.44]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id UAA14426 for <alsa-devel@alsa.jcu.cz>; Wed, 10 Feb 1999 20:21:15 -0500 (EST)
Message-Id: <199902110121.UAA14426@renoir.op.net>
To: alsa-devel@alsa.jcu.cz
Subject: Re: real-timing a la Golinvaux, Ashton 
In-reply-to: Your message of "Wed, 10 Feb 1999 18:58:17 EST."
             <Pine.SUN.4.03.9902101834030.17464-100000@severi.mit.edu> 
Date: Wed, 10 Feb 1999 20:21:36 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>hi folks,
>
>I am a little bit hesitant to speak up because my project is so far from
>seeing the light of day (you know, never announce anything until you have
>code) ... I just want to go on record with Benjamin and Michael as
>interested in _real-time_ music applications on Linux.  I am building what
>you might (if into buzzwords) call a "comprehensive next-generation music
>composition and modification framework".

Well, I'm also hesitant, though I'm not deep in code; timing is very
important for my Quasimodo project (http://www.op.net/~pbd/quasimodo),
but at the moment, I'm still unsure about how its all going to play
out.

It turns out that using the PCM device for implicit timing (i.e. I set
the sample rate to X Hz, and then know exactly how much time has
passed once N samples have been played) works fairly well. However, it
doesn't solve the latency problem by itself. Just because the ALSA (or
OSS) PCM driver decides to wake up a task once a certain
threshold/watermark is passed doesn't tell you much about when that
task actually wakes up.

Quasimodo, for the most part, wants very small amounts of buffering of
its PCM output by the driver, because it wants to respond "quickly" to
MIDI messages. Right now, I used about 3 2K fragments bytes @ 48KHz,
or about 0.06 seconds, of buffering. This works pretty well. Right
now, however, I'm also using the Pentium cycle counter to measure
things more precisely, since it gives me (on a 450Mhz CPU) resolution
down to about 20nanoseconds. Since I have a dual CPU machine, I am
actually busy waiting for periods of less than 1 usec sometimes.

Running the DSP thread in Quasimodo as RT_FIFO helps thing a lot. It
makes it possible to do busy waits for up to 2ms c/o the kernel, for
example, and because of the kernel's "need_resched" flag, reduces the
"driver-wakes-task" to "task-is-now-running" latency to the absolute
minimum (since the task gets switched to during the return from the
interrupt handler). This is very nice.

But RT_FIFO is limiting, because it requires root priviledge, and also
dangerous, so I'm unclear how realistic it is to use this mechanism
for programs intended to be run by "regular folk".

Just a few thoughts.

--p

