[LAD] SMPTE and jackd

gene heskett gheskett at wdtv.com
Fri May 11 14:01:39 UTC 2012

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 

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"

More information about the Linux-audio-dev mailing list