Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: David Olofson (david_AT_gardena.net)
Date: Sat Feb 10 2001 - 10:36:19 EET
On Friday 09 February 2001 13:36, Iain Sandoe wrote:
> Hi Steve!
>
> On Fri, Feb 09, 2001, Steve Harris wrote:
> > On Fri, Feb 09, 2001 at 12:19:49PM +0100, David Olofson wrote:
> >> On Friday 09 February 2001 11:57, Iain Sandoe wrote:
> >> > > - the time to [de]interleave data is a knats-p in a
> >> > > millpond compared to doing 600+ FFTs in real-time...
> >> >
> >> > Agreed.... and one can apply this argument to many facets of
> >> > the process... unfortunately you then end up with 10**N
> >> > gnats... which is one hell of a lot of p.
> >>
> >> Yep, another good argument. That's another reason why I'm not
> >> just throwing the pitch in.
> >>
> >> BTW, this pitch value is more easy to use than it may seem. From
> >> the Host perspective, it's just a matter of telling a Plugin how
> >> many physical channels a buffer has when connecting one of the
> >> Plugin's Buffer Slots to it. (Pitch is effectively # of channels
> >> * sample frame size in any normal buffer.) Use the channel
> >> number to index the buffer pointer when calculating the pointer
> >> to pass to the Plugin.
> >
> > Maybe I'm missing someting, but most complex plugins require
> > filters which require deinterleaving the data anyway.
> >
> > Also, I think you are better off (if you can) running small loops
> > over each channel in series, rather than a more complicated loop
> > over serveral channels at once - less cache polution.
>
> That depends on how you code multi-channel functionality.
>
> If you know, a priori, that you are dealing with a "stereo" process
> and have a simd machine it might pay to feed the samples in
> cross-wise blocks - keeping all execution units busy with the same
> instruction.
That seems to be pretty much the only way to do some recursive
(basically IIRe) filters efficiently with SIMD, BTW...
> This (for some of my applications) might become more acute (I have
> in mind scientific applications where I might have, say, 8 channels
> all considered and processed as a group).
>
> not, maybe mainstream requirement - but a couple of euros for the
> pot. Iain.
Yeah, this is the kind of processing I have in mind - otherwise I'd
just stick with the original idea of not supporting interleaved data
at all, or in very limited ways. (Converter plugins rather than
actual "transparent" support.)
However, where's "mainstream" headed?
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sat Feb 10 2001 - 11:08:20 EET