On Tuesday 31 December 2002 20.27, Paul Davis wrote:
So, my question
to this list is if someone has run a similar system
for days without underflows, and if there is some guide or tips on
how to
speaking personally, i have not. moreover, i don't believe its
possible with the current kernel, and probably will not be for the
foreseeable future. there are too many corner cases in the kernel
where the OS steals the processor for too long when running with this
kind of latency.
Is it even possible today to build an embedded
system with 1.5 ms
processing block based on Linux, which runs until hardware or power
failure?
if its based on RTLinux or some other variant of that idea, then
yes. but based on the regular kernel+patches, no, i don't think so.
I guessed that would be the answer. What do you personally think is the
lowest process block size that should provide reliable operation of a
carefully tuned Linux system? An important thing to consider, is that
the sound processing can take up as much as 90% of the processor time,
which increases the risk of missing a deadline if stuck in the kernel
too long for some reason.
I guess the question equals - how long can one be stuck in the kernel?
And from that one can calculate the rest.
I've thought about RTLinux actually, but it is simply too much work,
porting drivers to start with... It could make up an interesting
processing platform though, since a top of the line processor blows
away any DSP in terms of throughput, and with RTLinux or similar, one
could reduce the latency to at least a decent level as well. To really
make it worth it, nonuniform partitioned convolution algorithm had to
be free though (which it isn't). If anyone find prior art for that
algorithm (published papers before July 7, 1992 please) I really would
like to know about it :-)
Oh, my
software does not necessarily need to access any
filesystem while it is processing, although it would be good if it
could (to continuously save volume settings and similar if changed
through the remote control). So it can be seen as a strict
soundcard-to-the-cpu-and-back problem.
nothing in a multiuser, multitasking non-RT OS is ever a "strict
soundcard-to-the-cpu-and-back" problem :))
In this embedded case, there is only one user, root, which runs the
software. I'd like to make it possible to log in to the computer for
debug purposes, but it is not strictly necessary.
/Anders Torger