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)
Paul Barton-Davis wrote:
>
> >Flanging with a intersignal delay from 1 sample and up should be no
> >problem to deal with under linux. Just make sure that the total delay
> >of the signal is higher then the longest intersignal delay.
> >Interrupt rate or fragment size has nothing to do with this!
> >You may need to have an overal delay as a multiple of the fragment size.
>
> Precisely. I don't know of any dedicated FX processor that does
> this. They have a response time in the sub-0.05ms range,
> typically. This means that you can use them in a live situation
> without additional flanging caused by the additional delay introduced
> to handle the desired flange (or whatever effect it was).

Well, at least that's what you'd want from an FX processor. However,
dedicated FX processors are meant to be used as inserts in other
systems. (Usually analog mixers.) That means they have to recieve and
transmit data in one or another way... Which in turn means that there is
a minimum delay involved here, depending on digital interface bit rate
or AD/DA convertion times. (Bit rates are usually just a slightly faster
than the minimum required for the sample rate and number of channels,
and oversampling requires a time window...)

This means that there's NO WAY EVER to get a digital FX processor as
fast as an analog unit. As a result, some "all digital" units use analog
cirquitry for mixing dry and processed signals to the outputs.
Otherwise, there's no way to avoid a slight flange effect because of the
FX processor delay.

Important point:
As DAWs and other all-in-one processing solutions, like digital mixers,
have *virtual* insert jacks, those minumum delays apply only to the
physical inputs and outputs. That is, you get *exactly* zero latency in
a plug-in that doesn't intentinally delay the signal. No long insert
cords on your analog mixer to get near that! ;-)

That's why ProTools gets away with over 3 ms input->output latency...
(Does anyone know the exact figure, BTW?)

> Or perhaps I'm wrong, and even the lexicon's of the world add a 2ms
> delay to the signal and expect you not to notice :)

Perhaps not 2 ms on high end units, but nothing less than 0.05 ms or so,
unless they use analog mixing, or other special tricks. (You can control
a VCA using a DAC to build a zero [well, ns] latency dynamics processor,
for example...)

> >Setting up the sound card to run in circular mode and then MMAPing
> >the DMA buffer into user space allows for very close operation to
> >the hardware limits in terms of delays. The notion of fragments
> >is not relevant in the case of MMAP - the user level process gets
> >full control. It can, using tricks, easily phase lock on the DMA
> >input buffer. The DMA output buffer can then easily be driven.
> >If you have an SMP system these techniques are very useful!
>
> Certainly, and I thank you for your other mail that pointed out how to
> do the phase lock (never occured to me, since all my mmap() setups
> used the select()-based method described by 4Front, which is vastly
> inferior).

I found this quite interesting too. I might have something fun to play
with quite soon now... :-)

> I am hoping that Jaroslav will see this as a really good argument for
> ALSA providing the same exemplary service for mmap()-based access as
> for read/write stuff.
>
> However, this trick is useless for a software real-time synth or FX
> unit running on a UP system. Although I would be the first to argue
> that everyone should be buying dual systems these days, the fact is
> that many people want to use such software on UP systems that they
> don't want to replace (currently). So we need solutions that work for
> them as well.

Agree. Besides, when there are two CPUs, and 30% of one of them would be
enough to run the non real time system, why not use both for RT? Ok,
using 3 of 4 CPUs would be rather nice too, but...


//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.069 / U:2.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site