[linux-audio-dev] 1.5 ms latency possible?

Anders Torger torger at ludd.luth.se
Tue Dec 31 17:31:00 UTC 2002


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



More information about the Linux-audio-dev mailing list