Date: Thu, 08 Jul 1999 11:24:15 +0900 From: Seigo Tanimura <tanimura@naklab.dnj.ynu.ac.jp> To: julian@whistle.com Cc: Seigo Tanimura <tanimura@naklab.dnj.ynu.ac.jp> Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now works under New Midi Driver Framework with a Fine Timer) Message-ID: <199907080224.LAA20834@rina.naklab.dnj.ynu.ac.jp> In-Reply-To: Your message of "Wed, 7 Jul 1999 19:18:57 -0700 (PDT)" References: <Pine.BSF.3.95.990707191812.23943g-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 7 Jul 1999 19:18:57 -0700 (PDT),
Julian Elischer <julian@whistle.com> said:
>> Sorry, finetimer(9) is the new timer implemented in my latest midi driver.
>> You can read the short paper describing the feature and principle in:
>>
>> Message-Id: <199907060959.SAA05637@rina.naklab.dnj.ynu.ac.jp>
julian> how do I read that?
Ow, I thought it was in the mailing list archive, turned out not.
I will attach the paper below. Sorry for a long mail.
--- v --- cut here --- v ---
Unlike 16550, MPU401 does not generate an interrupt on TX-ready.
So we have to choose one of the following two options to drive
MPU401:
A. polling the status to wait until TX-ready,
B. emulating a TX-ready interrupt by a timer.
The option A, used by VoxWare(sys/i386/isa/sound/sb16_midi.c:sb16midi_out()),
consumes most of syscall time to wait for MPU401 to come TX-ready.
One byte of midi message takes 0.32ms to transmit. Some certain midi
sequences contain continuous long sysexes summed up to 200 bytes or
more, leaving a latency of 0.32 * 200 = 60ms or something like that.
This latency results in an unstable tempo.
I have chosen the option B to eliminate the latency on message
transmission. In this case, the timer needs to be capable of a period
less than 0.32ms. The conventional timeout(9) has a period of 1/hz[s],
which is generally 10ms. (hz = 100) While raising hz to, eg 3000 seems
to shorten the period of timeout(9) enough, many parts of the kernel
would be affected by this change, likely to end up with poor stability.
To solve this problem, I propose a new *fine* callout mechanism.
The realtime clock interrupt is at (hz * (1 << hzmul))[Hz], where
(1 << hzmul) is the mutiplication ratio of hz. Although the ratio can
be any natural number in theory, I have chosen the power of two to
reduce the computational cost of the clock divider. (discussed later)
As desceribed above, (for i386) clkintr() is called at
(hz * (1 << hzmul))[Hz], calling hardclock() at the same frequency.
hardclock() has two elements in it: a callout detector and a clock
divider. A callout detector traverses the callout list and makes
a callout, as in softclock(), except that the IPL stays at splclock.
A clock divider reduces the frequency to hz[Hz], to process the
conventional hardclock(), which is now renamed to hardclock1(), and
softclock(). Although dividing a clock tick generally involves a
costing division operation of the dividor counter by (1 << hzmul),
a ratio of 2^n allows us to replace the operation with a simple
shift of (clkdiv >> hzmul), where clkdiv is the dividor counter
incremented one by one on a hardclock().
Fig 1 shows the frequency and the IPL of the new timer handlers.
Frequency IPL
Timer ^ ^
Generator | |
| | |
v (hz * (1 << hzmul))[Hz] splclock
clkintr() | |
| | |
v v v
hardclock() -> Fine ________________________________________
| Callouts ^ ^
v | |
hardclock1() | |
| hz[Hz] splsoftclock
v | |
softclock() -> Conventional | |
Callouts v v
Fig 1: Call Frequency and IPL under New Timer Handling
I have implemented the new fine callout system discussed above
in the latest patch of my midi driver. hzmul is 6, to multiply the
timer frequency to 6400Hz. The usage of the fine callout is the same
as timeout(9), except for the prefix of fine-, and that the granularity
of the ticks is (1/(hz * (1 << hzmul)))[s]. Although I have not done
any quantitative evaluation yet, I played some midi sequences with
sysex messages to show a picture on the LCD of my SC-88, recognizing
no latency like VoxWare. This result states the effectiveness of my
proposing fine callout system. The future works include porting to
alpha and PC98, and tuning hzmul.
--- ^ --- cut here --- ^ ---
Seigo Tanimura <tanimura@naklab.dnj.ynu.ac.jp>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907080224.LAA20834>