On Wednesday 16 June 2010, Patrick Shirkey wrote:
>On 06/17/2010 04:52 AM, Ralf Mardorf wrote:
>> Paul Davis wrote:
>>> On Wed, Jun 16, 2010 at 2:30 PM, Ralf Mardorf
>>>
>>> <ralf.mardorf@email-addr-hidden-dsl.net> wrote:
>>>> PS: Why not programming for savant syndrome musical gifted and 'fast'
>>>> watching people too?
>>>
>>> the limits under discussion relate to monitor technology, not human
>>> capabilities.
>>
>> I'm not a 'fast watching savant' ;) and even if the GUI is too slow, I
>> won't care. I'm listening to music with my very good ears, but my bad
>> eyes. No doubt, Linux is a good choice, but MIDI real-time could be
>> better. For me the GUI is unimportant. BUT I prefer to do audio
>> recordings using Linux, but MIDI recordings. It's a real pity, because
>> MIDI would add some very cool features.
>
>This is only on your system right? I know a lot of people are working
>with midi recording using linux tools.
>
>You see jitter at low latency but have you tried changing your hardware
>or working with the driver developers to isolate and fix the bugs you
>are seeing?
One of the test tools that might be enlightening for the MIDI folks here, is
the machine control program called emc. Because jitter is very important
when feeding a stepper motor controller a steady heartbeat at high audio and
somewhat above frequencies, the coders have developed a 'latency-test'
script, which you run on one screen, then abuse the heck out of the machine
doing other things, (browsing the web, moving windows around, compiling a
kernel, whatever warms up the cpu) then come back half an hour or more later
and read the average and worst case latencies as displayed in nanoseconds.
Those are generally big figures so do the math and make milliseconds out of
them.
Emc when running stepper motors is fussier that all get out, and that tool
just might point the finger at truly bad motherboard, or video hardware.
FWIW, an nvida video card, can only be used in a machine running emc if the
vesa driver is selected, all the others including nv, tie up the interrupts,
sometimes for many milliseconds. For emc, that would equal a stalled motor
and a wrecked part you were cutting at the time it stalled. Similar things
can be said about the APCI of some motherboards. If that can't be fixed via
a bios setting, toss the board. Via chipsets seem to be the most popular in
this latter category.
If its a complex part that you've already got several hours worth of carving
& cutting tool wear into, that will only happen once, because whatever the
culprit is, gets both found and a free airmail trip into the bin.
What? Oh, I'll go back to lurking now. ;-)
-- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The policy is not to have policy. It works as well in kernel design as politics. - Alan Cox on linux-kernel _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Thu Jun 17 04:15:03 2010
This archive was generated by hypermail 2.1.8 : Thu Jun 17 2010 - 04:15:03 EEST