Subject: Re: [linux-audio-dev] Software filter engines for high end audio and now DSP's
From: Benno Senoner (sbenno_AT_gardena.net)
Date: ke helmi 16 2000 - 17:28:26 EST
On Wed, 16 Feb 2000, Anders Torger wrote:
> On Wed, 16 Feb 2000, you wrote:
> > That is why I am still dreaming about an "audio operating system",
> > ( MuCoS) which would provide an abstraction layer to run your
> > native audio processing components on top on a high performance OS.
> > (in this case Linux).
>
> How about RT Linux? It exists today.
yes, but it will not be accepted into mainstream linux very soon.
plus ask David Olofson how difficult, it is to port soundcard drivers,
write plugins in kernel space ( a crash will take your box down) etc.
I'd prefer 1-2ms more latency using a std kernel (with lowlatency-patches).
>
> > The only hurdles for useful native processing until now were:
> > - CPUs too slow , (this is changing because we are approaching the GHz
> > frequency range, plus CPUs are more and more equipped with DSP-like instructions
> > ( MMX etc) which will speedup greatly the DSP processing.
>
> What I have noticed when I made the WFIR and FIR engines, is that one wants a 64
> bit processor. The reason is that 32 bits is not enough as accumulation
> register. 56 bit is common in DSPs, and is the least one need. It is possible
> to accumulate to 64 bits on the IA32, but then you need to use two 32 bit
> registers and a cumbersome clock-cycle eating way of adding numbers. When it
> comes to MMX, it is only suitable for 16 bit data, making it irrelevant for
> high end use, I thought at first. But with some tricks it is possible to use it
> anyway while maintaining signal quality, however the input is limited to
> 16 bit. But 24 bit @ 96 kHz is anyway today a too high data rate for most real
> time applications running on standard hardware.
agree, but single precision floating point is quite fast, the Athlon can do
up to 2 single precision FP ops per cycle, that is 1.6GFlops at 800Mhz.
>
> By the way, has anyone tried clustering machines (preferrably Linux boxes) to
> do real time audio processing? I'm especially interested in FIR filters with
> more than 15000 taps. It must be a problem to keep latency low in these
> systems. I have thought of the idea to use digital soundcards for data transfer
> between the machines in the clusters, must be perfect for low latency hard real
> time data transfers [at limited rates]. However multichannel digital sound cards
> are a lot more expensive than network adaptors, so I guess it is just a wierd
> idea :-)
I think using 100Mbit cards in fullduplex mode with cross-cables (old discussion
here), we can get reliable <1-3ms latencies between machines.
I think if you plan the enviroment well enough, a 5-6ms I/O latency cluster
isn't impossible.
I don't think that using soundcards to do data communication is a good idea.
I'd rather prefer other methods, like high-speed serial or parallel interfaces.
But I am still convinced that 100Mbit fullduplex + crosscable + running a
special protocol ( RAW IP without arp etc ? ), will meet our requirements.
That's one of the things I want to figure within the next 6-12months.
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST