Re: [linux-audio-dev] protux, stereo and interleaving

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: Richard C. Burnett (burnett_AT_tality.com)
Date: Fri Feb 09 2001 - 21:14:10 EET


It is probably true that material deamed for playing only would be
interleaved as this would be the best case. Mainly you could read in much
easier and it lends itself to the system better too. But as Paul
mentioned, and I wanted to reiterate on that keeping the sound separate
makes much more sense for multitrack sound development systems. First,
most people think in stereo, and many programs get hard coded that
way. With todays new sophisticated systems, its just not so
anymore. Likewise, in an editor, the final product is merged down to 1,2
or even 6 tracks (Dts ect). So if you were to be adding tracks to a song,
would you then interleave that into the existing data (Very time
consuming) or would you group them in pairs. What about when you have
certain segments of sound that happen only for a small time somewhere in
the song, would you pad the rest of the interleaved data with 0 data? You
can see it clearly gets memory intensive. There are tons of audio
formats, but I see two main categories; fixed data and dynamic
data. I do alot of work with Samplitude right now as Ardour is still in
development, and data is stored in seperate files. I will give one minus
to samplitude and thats that it has a stereo mode where the sound is
interleaved and stored in a file, and if I do things with this mode, I
cannot edit each side as well as if I just make a full mono project and
hard pan the channels.

My 2 cents :)
Rick

On Fri, 9 Feb 2001, Paul Davis wrote:

> >frames are interleaved by audio channel. Overall, interleaved data seems
> >much more generic, and real-time friendly. Is it really such a
> >performance-killer - the time to [de]interleave data is a knats-p in a
> >millpond compared to doing 600+ FFTs in real-time...
>
> true. but if you store a 40 minute 24 channel recording in interleaved
> format, editing it becomes extremely difficult, even with
> non-destructive techniques. destructive techniques would require
> rewriting all 24 channels at and beyond the location of any deletion.
> non-destructive techniques can avoid the rewrite, but you end up
> either doing massive amounts of duplicate data i/o and/or using a very
> complicated caching system between the file and the presentation
> system.
>
> i don't think its a coincidence that most high end audio software
> suites use non-interleaved storage formats.
>
> and as someone else pointed out, SIMD encourages this approach as
> well. i'm not sure that we have any good SIMD-capable compilers at
> this time, but thats just a detail :)
>
> --p
>

+------------------------+-----------------------+
| T a l i t y | +------+ |
+------------------------+ +----+-+ | |
| Richard Burnett | +-+ | |
| Senior Design Engineer +---+ +----+ |
| burnett_AT_tality.com | | |
| | | |
| Phone: 919.380.3014 | |
| Fax: 919.380.3903 | | |
+------------------------------------------------+


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Feb 09 2001 - 21:32:21 EET