Someone called illiac wrote:
> Linux as it is ordinarily distributed is not a
small-footprint real-
> time operating system. You will notice that your cell phone does not
> run Linux. There is a reason for that.
i am sure nokia will be interested in your reason, since they don't seem
to have heard of it yet. there are many cell phones that run linux. lets
move on to the next basic error in your message:
> There is also a reason that the MPC4000 is a
zero-latency device
> whereas a PC, even one running
no digital audio device is zero-latency, least of all one with analog
i/o's.
> Linux, is not a zero-latency device; it requires
audio buffering and
> latency compensation and all that sh*t that drives people to work
on
latency compensation has absolutely nothing to do with what you are
describing. audio buffering is caused by the design of the PCI bus, not
linux. it also happens to reduce CPU load, which most people
appreciate.
> If you haven't designed a real-time embedded
application before --
> e.g., the software that controls a piece of machinery or electronics
> -- then you are not in a good position to offer advice about how
> best to do this.
if you have no experience with just real-time current linux kernels can
be, then you are not in a good position to offer advice on how best to
do this.
> There are public-domain RTOSes available that are
suitable for this
> task. To those, you can add drivers for USB and FAT32. Without an
> RTOS to give you hard real-time scheduling, you have no chance to
> achieve the rock-steady timing that the MPC currently has.
that sucks. that really does. because my linux systems have the same
rock steady timing as the MPC. actually, their timing is even better
than the MPC. somebody must have made a mistake around here.