13 Jul
2005
13 Jul
'05
5:42 p.m.
On Wed, 2005-07-13 at 10:27, Lee Revell wrote:
On Wed, 2005-07-13 at 18:31 +0200, Florian Schmidt
wrote:
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
On Wed, 13 Jul 2005 10:49:11 -0400
Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> wrote:
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. 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?