Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

Fernando Lopez-Lezcano
2005-07-13T20:49:42Z

On Wed, 2005-07-13 at 12:33, Martin J. Bligh wrote:
> --On Wednesday, July 13, 2005 14:32:02 -0500 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> > Hi,
> >
> > On 7/13/05, Lee Revell <rlrevell@joe-job.com> wrote:
> >> On Wed, 2005-07-13 at 12:10 -0700, Linus Torvalds wrote:
> >> > So we should aim for a HZ value that makes it easy to convert to and from
> >> > the standard user-space interface formats. 100Hz, 250Hz and 1000Hz are all
> >> > good values for that reason. 864 is not.
> >>
> >> How about 500? This might be good enough to solve the MIDI problem.
> >>
> >
> > I would expect number of laptop users significatly outnumber ones
> > driving MIDI so as a default entry 250 makes more sense IMHO.
>
> Could someone actually test it, rather than randomly guessing? ;-)

A Midi NoteOn command (ie: the equivalent of pressing a note on a
musical keyboard) transmitted through a physical Midi interface is
around 1 millisecond long with no running status, or 0.64 msec long with
running status going on (that means one note in between other note
on's)[*].

Scheduling of midi output should rely on a timing source that has a
better timing resolution than that. So, HZ=1000 let's us sort of
correctly schedule note-on (and similar sized events). It already
introduces jitter in two byte critical messages like MTC (Midi Time
code) Quarter Frame messages.

-- Fernando

[*] basic midi bit rate is 31250, one midi byte is 10 bits long,
commands can be one, two, three or more bytes long. Midi commands are
made of one status byte and optional data bytes, the status byte can be
ommited on multibyte messages for consecutive messages that are of the
same type (called "running status"). Real time commands such as Midi
Clock can be sent at any time, even in the middle of an already ongoing
midi message.