| |||||||||||||
|
| |||||||||||||
What is Real-Time?What is Real-Time?Posted Dec 29, 2004 3:54 UTC (Wed) by jwb (guest, #15467)In reply to: What is Real-Time? by jd Parent article: Where Is Real-Time Linux? (TechNewsWorld)
I liked your example, right up until you started talking about jitter. There's a perfectly good way to keep everything phase-aligned, because the ADC latches the sample into a buffer at exactly the right moment. Then the OS simply needs to come around and read the samples out of the buffer, and it needs to read all 10 samples before the next sample is latched. Even more likely, the samples are being transferred via DMA into a ring buffer in main memory, meaning the OS needs neither polling nor interrupts to work properly. The audio application can consume the samples as aggressively (e.g. jack, asio) or as lazily (e.g. record to file) as it likes.
Which just goes to show there are perfectly good hardware solutions to realtime problems. Anyone relying on an RTOS to achieve low-jitter sampling is going to be sorely disappointed, and frankly anyone who implemented your fake dithering scheme in a real recording system should be ashamed.
(Log in to post comments)
What is Real-Time? Posted Dec 29, 2004 20:36 UTC (Wed) by jd (guest, #26381) [Link] I agree. Actually, I believe there are perfectly good hardware solutions to the majority of software problems. (Should someone ever convert Linux or Glibc into a raw, hard-wired hardware solution leaving the CPU 100% free to spend time on actual processes rather than housekeeping tasks, I could easily see computers increasing in performance five-to-ten-fold in a single step.)My understanding of the problem, as defined, though, was that it was wanting to know software solutions to a software problem, with a preference on using what they had as far as possible. I therefore focussed on getting the absolute best data possible, using computational and statistical tricks, out of their software and hardware. Sure, it's not "the best" or "the neatest", but it does work. As for the jitter, that was a "last resort" for when every other technique given just doesn't get close enough to what's wanted, AND where the problem is of a statistical and not a technological nature. It was never intended as a "first step", and apologies if I wasn't clear on that. It was intended far more as a "you've done everything technically possible, you've still got an error in the way the sampling is done, maybe the problem is in the nature of the data, not the nature of the application" type of solution. You can't, using any method, get more information out of some data than there is to start off with. You can't make something out of nothing. But what you can do is use various techniques for creating the illusion of having something better than you actually have. If you're not actually using the data for hard science, such as a nuclear accelerator experiment, but rather for something less "critical" such as music, then producing something the ear/brain perceives as "better" is good enough. P.S. If any chip manufacturer reads LWN, I mean it. Raw hardware Linux and/or raw hardware GLibC (preferably both) would absolutely massacre anything that's out there today. Both are relatively stable today, so such work would still be commercially valuable by the time it was finished, and likely for a good few years after. Besides, it would be one of the greatest hardware hacks since Intel came up with the microprocessor.
What is Real-Time? Posted Dec 29, 2004 22:32 UTC (Wed) by flewellyn (subscriber, #5047) [Link] Hmm...how about firmware? Fast loading, much of the lower-level primitives actually in hardware, and no need to worry about mapping address space for the kernel code to live in.
What is Real-Time? Posted Dec 30, 2004 0:13 UTC (Thu) by jd (guest, #26381) [Link] Firmware would be a good compromise, and there's enough microcode to allow for updates of the higher-level stuff. You wouldn't get quite the speed of raw hardware, but it would be much, much closer.!Evil Scheme Alert! Actually, it could be quite interesting, as firmware, as you could then have devices that ran their own private instance of Linux on them. You could then stub out the handlers for those devices in the Linux kernel running on the primary OS, leaving just some sort of message passing code to instruct the micro-Linux kernel on the device. This would simplify what you'd have to put in any given component of the system (making it easier to do, cheaper to do, and possibly faster to run). Also, instead of running a heterogenius collection of disparate firmwares on incompatiable systems, you'd be running one homogenius distributed machine on a highly uniform platform. (You'd also - finally - be able to do neat QoS stuff on inbound traffic, without having to resort to the IMQ patch.)
|
|
||||||||||||