Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: Iain Sandoe (iain_AT_sandoe.co.uk)
Date: Sat Feb 10 2001 - 13:38:58 EET
On Sat, Feb 10, 2001, David Olofson wrote:
> 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?
Please note, though, I'm 100% behind PBD's observations re. "studio"
channels & so on. There is nothing more frustrating the record/edit process
than arbitrary grouping of channels forced by some non-transparent part of
the underlying structure.
de-interleaved (or non-interleaved) is essential for those jobs - so I guess
(as I think you are saying) both is the real requirement.
An effective/nice way of locking channels together (post record) is also
very useful.
For example, I quite often record "live" in the studio and then want to
relate the recording back to Old-Fashioned Western (tm) bars/beats etc. So
that other tracks can be added on a sequencer approach.
It is essential to lock the tracks exactly because one will be fiddling with
the "notational timebase" - this affects the start time of the audio (in
bars/beats) and it must affect _all_ the audio the same...
ciao,
Iain.
This archive was generated by hypermail 2b28 : Sat Feb 10 2001 - 14:56:30 EET