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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
