Subject: Re: [linux-audio-dev] 1.5 ms latency possible?
From: Anders Torger (torger_AT_ludd.luth.se)
Date: Wed Jan 01 2003 - 00:24:11 EET
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
This archive was generated by hypermail 2b28 : Wed Jan 01 2003 - 00:28:32 EET