Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2

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

Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 18:27:50 EEST


>them! Let me try again. If there is no difference in how plugins use the
>channels (that is, if the api is the same regardless of the underlying
>channel type) why should the plugin be given the information?

A plugin has a UI. The user says "I want to connect the output of this
internal object to physical channel #1". The plugin does:

       channel_id_t chn = hardware_id (1);
       request_channel (chn, PLAYBACK);
       ... store chn in the internal object ...

The user says "I want to connect the input of this internal object to
internal bus #5". The plugin does:

       channel_id_t chn = bus_id (5);
       request_channel (chn, CAPTURE);
       ... store chn in the internal object ...

In both cases, the plugin then calls:

       read_from_channel (chn, ....)
       write_to_channel (chn, ....)

is this complex?

>You are already coming up with additional channel types (network) and
>I can think of a few more (disk, proprietary firewire protocal, video
>stream).

I fully retract the suggestion of anything except audio i/o and
internal bus channels. Fully. network routing can be handled by an
additional plugin and sending data to it over the bus system. So
forget it, the idea is gone. Dead. Buried.

>Here is a quick example:
>
>2 apps that read and write 26 channels are connected in series
>
>input -> app1 -> app2 -> output
>
>In your model there would be 26 channels, 26 buses, and 52-104 float
>buffers (26 for each app for each input/output - input and output could
>possibly be the same).

actually, no, because any sensible implementation (e.g. ardour as of a
few days ago) will avoid cache thrashing and use the same float buffer
for all of its internal objects (or some small number thereof, if the
internals allowed parallel execution).

so in this case, there are 26 channels (no memory), 26 busses (memory)
and 2 float buffers.

>http://www.cs.princeton.edu/~prc/SKINI09.txt.html

Yep, I like SKINI. But as I recall, it has typed messages, which
LADSPA does not support.

>> this is never going to work in the multichannel case Karl. right now,
>> in ardour, a 1.3ms period at 48kHz takes about 0.8msec to compute with
>> 24 active channels of disk-based data and no plugins. I think I can
>> reduce that (its without any optimization for a start), but a lot of
>> that overhead comes from function call chains that will never be
>> inlineable. To execute those same call chains one sample at a time
>> across 24+ channels will be impossible on today's processors.
>>
>
>Depends on when you do the inlining :) There is no reason that you can't
>create the run/run_adding method from the tick method at compile time and
>connect the block (i.e. run methods) at run time.

I take it that you're kidding. On an x86 architecture, there's an
order of magnitude too few registers for such inlining to make any
sense at all. In an Ardour Route, we have signal flow:

  input->pre_dsp_send->dsp_plugins->post_dsp_send->pan->gain->output
              | | | |
             out out out out

that chain is executed for every route in Ardour, every time we are
called from the engine.

there is no way you could inline all the code involved in that chain
and expect to see sensible register allocation.

<digression>
the original point of function calls in the first place
was to avoid exactly that kind of effect - you say "i temporarily give
up using the registers so that i can do something else with them; oh
good, now that its done, i'll restore the registers to how they used
to be and carry on." the alternative is to somehow pick through the
mass of inline code and identify which variables belong in registers,
something that compilers have never been very adept at on a large
scale (they can do it very well inside a small function with a fairly
small number of local variables). you may recall the "register"
declaration in C, which was specifically aimed at helping compilers
with this issue; its not normally needed these days, but with that
much code inlined, the compiler couldn't do it, and I'd wager to
guess, neither could a programmer.
</digression>

--p


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

This archive was generated by hypermail 2b28 : Thu May 10 2001 - 18:46:18 EEST