lkml.org 
[lkml]   [1999]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: real-time threaded IO with low latency (audio)
Steve Underwood wrote:
(...)
> Lets say I want to put a full duplex speakerphone facility on my desktop. I
> need a small echo cancellor for the line, and a large acoustic one. I need to
> keep the pipeline through the machine down to a a couple of 8kHz samples. If I
> make the delay much greater I won't properly comply with Telco regulations, and
> the line echo problem will just get worse. Cancelling the echoes and
> continuously estimating the echoes takes a lot of CPU power, and even on a
> 500MHz machine the acoustic cancellor will only be a compromise one. This is
> certainly a genuinely useful real world example of low delay audio processing.
> The only way I have managed to reliably solve this kind of problem on a
> dedicated DSP chip is by putting the echo cancellors inside the interrupt
> service routines, and letting the chip spend almost all its time in interrupt
> service. If you want really low delay audio I think you will always have to use
> that type of strategy.

That can be done with RTL interrupts. They preempt everything, and can
block out everything until the work is done. But off course, due to
cache misses and other problems related to workstation type machines,
the jitter can never be as low as on a small, dedicated DSP system with
only fast RAM, L1 cache and no disturbing processes messing with the
cache when the real time interrupt isn't working.

And as I don't intend to spend 70% CPU time on context switching, I'm
not expecting to get down to the kind of latencies where the latency in
the converters is starting to become an annoying problem. I just want
slightly better performance than current native processing DAWs, and
most importantly a RELIABLE solution, usable in any place an ADAT or
dedicated hard disk recorder is used now.

> Real time OS's don't help much if you want _really_ low latency. I spent years
> developing low delay DSP, and was never able to use an OS of any kind.

I'm not surprized... The only thing that makes modern workstations
usable for low latency hard real time jobs is raw power. Caching and
other "phenomena" will always add jitter in the range of a few bus
cycles. Nowadays, we're talking microseconds here...

Check out http://www.zentropix.com/support/document/testdata.html for a
hint on where RTLinux was a while ago. The performance is being improved
constantly.

> The
> delay through a good quality flanger (or for that matter, almost any audio
> effect) for the unmanipulated component of the sound should be just a couple of
> samples.

I don't argue that...

> Anything greater will alter the effect when the sound in the room is a
> combination of the processed and unprocessed paths.

...but I certainly would NOT like this situation in a digital studio!
That's a basic user error.

A DAW is audio in -> all kinds of processing -> audio out. If you use
ANY form of digital effect as an insert effect on an analog mixer, you
have to be aware of the side effects anyway, and they are always present
as long as the digital effect is truly a digital one. (That is, not
based on DCAs or other zero latency components in the signal path.)

> You only get such low
> delays by very tailored solutions.

Offcourse, but IMO, it's a waste of resources in this kind of
applications. A digital audio workstation is not an active servo control
system or something like that.

And an additional note: The monitor speakers are usually not on the
exact same spot as the listener or the sound sources, and mics are
always some distance away from the source.

Hint: How fast does sound travel in air?

This makes any "problems" related to mic -> monitor latency quite
irrelevant in real life situations. Moving the speakers will affect
latency more than Audiality...

> Audio effects on general purpose computers will always be a compromise. How
> large a compromise would you like, Sir?

A very good one, please! :-) That means low latency enough for normal
monitoring conditions, while not burning most of the CPU power on
context switching. This is perfectly sensible and possible to do on a
good hard real time OS.


//David

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.136 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site