On Wed, 2005-07-13 at 10:27, Lee Revell wrote:
> On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt wrote:
> > On Wed, 13 Jul 2005 10:49:11 -0400
> > Eric Dantan Rzewnicki <rzewnickie@email-addr-hidden> wrote:
> >
> > > > Correct, it's not an issue for apps driven by hardware interrupts like
> > > > JACK, because the sound card consumes data at a constant rate. But for
> > > > MIDI or video where you have to periodically push data to the device it
> > > > matters.
> > >
> > > What is driving the kernel-devs to regress on this issue?
> >
> > Well, i suppose it's a tradeoff between throughput and responsiveness.
> > Larger timeslices increase system throughput (less time is spent in the
> > scheduler) while smaller timeslices increase responsiveness.
>
> Someone proposed HZ=864 which might be OK.
>
> Can someone tell me what the minimum HZ you would need to send MIDI
> clock or MTC would be? I think this is a good place to draw the line.
The midi bit rate is 31250, midi bytes are 10 bits long (8 data bits, 1
start bit, 1 stop bit or so I seem to remember), so that'd be .32 msec
per byte. A note on command without running status would take 3 bytes,
or 0.96 msec, or approx one millisecond.
MTC (Midi Time Code) critical messages are the Quarter Frame messages,
which are two bytes long. So, 0.64 msec long.
Midi Clock messages (a completely different animal) are single byte, so
0.32 msec long and can be sent _anytime_, even in the middle of any
other type of message.
So, worst case scheduling would seem to me to be around 0.32 msec (ie: I
want the message to be sent at time t+/-320 usec).
This would be for messages that are not sharing the midi stream with
other messages. When you do share the scenario changes. Depending on the
type of message and what is already being sent out the wire we may need
to wait one, two or three midi bytes before we can actually send it, so
we could think of relaxing the requirement to 0.64msec or 0.96 msec. A
stand alone MTC stream (no other midi data sharing the cable) would need
to be scheduled worst case with a precision of one midi bytes (0.32
msec). BUT: I don't know how much jitter external boxes would be able to
tolerate and still sync to the source - and I think that is what would
define what we can get away with in terms of relaxing HZ. I do seem to
remember that HZ=100 made that impossible.
This is taking into account physical Midi bandwidth limitations.
For internal connections through the ALSA sequencer the bandwidth
limitation is gone and we are left with either saying, well, it has to
be at least as good as a cable in terms of scheduling accuracy or we can
drift into perceptual issues such as how much jitter is acceptable in a
rhythmic note-on stream from the point of view of a musician listening
to or playing with it.
We really need high precision timers.........
Or a boot-time choice of HZ value.
-- Fernando
Received on Thu Jul 14 00:15:29 2005
This archive was generated by hypermail 2.1.8 : Thu Jul 14 2005 - 00:15:29 EEST