13 Jul
2005
13 Jul
'05
9:03 p.m.
[ Fernando Lopez-Lezcano ]
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).
If you want jitter-free MIDI clock, that is absolutely correct. OTOH,
I often wondered why MIDI interfaces are not designed to work in the
same way as an audio card: you write a period of frames, and the HW
takes care of the exact timing of each one. The same could be done
with midi data. It would introduce the same latency we have on audio,
but at least there would not be any jitter.
[ Eric Dantan Rzewnicki ]
I expected something like this. But, I guess my
question was more, who
is complaining about HZ=1024? To which I guess the answer would be
everyone who is more concerned about throughput than latency. Though,
somehow I think that everyone needs a good balance between the two.
I'm not on LKML, but I read the thread from the archives. There seemed
to be two main issues about HZ=1000:
* Some people reported that a kernel build would take 5% more time.
I'd be surprised if this were true. It would mean that the timer
interrupt itself takes 5% of the CPU cycles, and I never noticed that
on my CPU load monitor. And if it is true, it probably means there are
some routines on the timer chain that do not need to be woken up 1000
times per second, and should be on a derived lower frequency task list.
* Apparently, some laptops are draining their batteries at an alarming
rate (in sleep mode) as a result of the 1000 HZ. This could be true, but
indicates a design problem IMHO.
[ Paul Davis ]
no, to make everyone happy we need the High Res Timer
patch. that avoids
the stupidity of a fixed HZ, which is so early '90s that its
embarrassing.
Agreed 100%. I just wonder about the availability of the required
chip on mainstream motherboards. My machine (2 years old now) doesn't
have it, as far as I'm able to find out. Does anyone have more
visibility on this ?
--
FA