Re: [linux-audio-dev] a new application underway

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

Subject: Re: [linux-audio-dev] a new application underway
From: David Olofson (audiality_AT_swipnet.se)
Date: ti loka   12 1999 - 02:00:49 EDT


On Tue, 12 Oct 1999, Paul Barton-Davis wrote:
> specifically, i'm looking at a situation where i've got N channels of
> interleaved data read from a soundcard, sitting in a buffer. a mixer
> strip picks up 1 channel from this buffer, and mixes it into 1 channel
> of the output buffer.

The nice little data format problem again...

> the simplest way to route input to output would be to have each node
> in the processing net act like a proxy, and have it additively combine
> the relevant (think interleaved) data from the input buffer with the
> relevant (again think interleaved) data of the output buffer.
>
> i say proxy because i'm talking about using function calls that hide
> the additive combination. this prevents the node from seeing the data
> that constitutes its input.

Not quite following... Matrix operations? Anyway, why not inline
macros or functions, if it's "just" a matter of interleaved samples?

> but even in the common cases, we'd like to know, for example, the RMS
> level of a strip's input. if it only has the mix function, it has to
> compute the RMS level of the output buffer beforehand, then recompute
> it again after the mix.

No. Just simulate the replacing version as usual - using a separate
buffer that you clear before you call process_mix(). (The same buffer
can be reused a whole lot, as it's contents are not needed anymore
after the last reader has accessed it during the current cycle.)

However, it *does* mean that you need to do the *actual* mixing using
the standard, built-in mixer "plug-in"... So the replacing process()
function makes a lot of sense after all, in cases where you want to
connect an output to multiple inputs.

So, replacing process() is in. process_mix() is still little more
than a low level, DSP code performance hack. Now, is *that* version
actually useful, or does it just mean extra code?

BTW, buffers and the cache: Use a LIFO stack as a heap of buffers.
balloc() (*hehe*) picks the top one, and bfree() puts one back. That
way, balloc() will in most cases give you a buffer that has been used
not long ago.

> so, this is what i'm carefully considering how to avoid in a
> multitrack mixer.

That's a bit hard without building the VU (or whatever) into the
plug-in... Careful combination of standard functions into a set of
basic plug-ins is the most efficient way I can think of right now.
But that doesn't help much if you hit this problem directly after
some alien plug-in.

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


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

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST