Re: real-time threaded IO with low latency (audio)

Paul Barton-Davis (pbd@Op.Net)
Sat, 24 Jul 1999 11:24:05 -0400


>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).

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 :)

>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 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.

--p

-
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/