Re: [LAD] SMPTE and jackd

On Friday, May 11, 2012 09:17:37 AM Jens M Andreasen did opine:

> On Fri, 2012-05-11 at 07:34 +0200, Ralf Mardorf wrote:
> > That's why
> > Paul explained it (to us/me) and he's right.
>
> No, that's crap ... "Many" (which one?) is not equal to ALL. Just
> because some idiot hired gun working for a no-name-brand couldn't be
> bothered, does not mean the whole world is condemned to doing things the
> wrong way. Trash that machine or use it as a doorstop ...
>
> ;-)

I think I'll have to agree with Jens here. If the hardware can't do it,
put it someplace it can do something useful, door stop or window prop as
needed.

Since I'm involved with a totally different area that is also _extremely_
sensitive to real time, absolutely on time performance, metalworking
machine tools that position the cutting tools with stepper motors, as a
field we tend to gravitate to what works, with IRQ latency being nearly the
sole judge of what works and what works poorly or not at all. The machine
we've found to be the current best of the crop is one that is dirt cheap,
I've bought 2 of them so far for about $250 USD ea. Complete shoeboxes,
decent sized hard drives, 2Gb of memory, onboard video, even a good parport
for our uses, a true set the bios, load up the software and go box. The
magic ingredient is an Intel D525MW motherboard, carrying a passively
cooled, 1.6 Ghz dual core Atom cpu. We disable hyperthreading as its a
time waster of legendary proportions, boot an RTAI enabled kernel, using
the isolcpus=1 command, so the non-real time stuff runs on core0, and the
real time on core1. Typical latency test figures are in the 2.5 u-s range
and we run the base-thread at 25 u-s between loops, or 40 kilohertz. Using
motor drivers that microstep the motors by doing a /4 or /8, even a /16,
the motors can be turned quite a few hundred rpms. These motors need a
steady heartbeat to do that, and a poor machine will limit motor speeds by
missing a step, causing the motor to slow or even stop and when this poor
machine finally does get around to issuing more steps, the motor is slowed
or stopped and cannot accelerate back to full speed so it loses a step and
stalls. A hung motor and likely a wrecked part because the motor on a
different axis didn't stop.

I don't see why the same, absolutely on time criteria for good performance
wouldn't apply to the audio processing and scheduling needed to perform
fantastically well for audio. And its not a one trick pony either, I can
carve steel on my milling machine while editing the next bit of code in
another window, with an IRC client logged into 4 channels, plus a copy of
firefox running so I can check out links that might be posted on one of the
irc channels, and do it without bothering the milling machines progress.

So I have to agree with Jens, if the hardware cannot or won't do it, find
hardware that will and use that one for something else or recycle it.

And, when you do find something that Just Works(TM) for your use like the
Intel D525MW board kits do for us, be sure and publish it here as that will
drive sales for the unit, telling the maker he has done something right
because there has been a visible uptick in sales.

Basically if you want good hardware that does work, tell the world what
does, and does not, work.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Whatever you may be sure of, be sure of this: that you are dreadfully like
other people.
		-- James Russell Lowell, "My Study Windows"
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev