Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Thu May 10 2001 - 20:53:26 EEST
On Thu, 10 May 2001, Paul Davis wrote:
> >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?
>
The complexity lies in the fact that all of the applications have to have
user interface to do the connections - it is not necessary a matter of
implementation complexity as it is conceptual complexity for users. The
real point is about constraining server implementations. In your model
only server
> >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.
>
OK.
> >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.
>
Yes, but there is still an additional set of buffers for _every_ bus even
in cases where an intelligent server implementation could do away with
them. Also, aren't you worried about the overhead of copying in out out
of the buses? Finally, are there any drawbacks to my suggestion that you
see? Let me restate it concisely:
1) Use LADSPA (potentially make run_adding the default a la RTCmix)
2) Write a server that solves the signal flow graphs for efficiency
(PureData, Max/MSP, jMax).
You like to bring up that models that exist and work now are important.
This is definitely true and there are a lot of models that have been
refined for years in the computer music world that you are not
considering. Steinberg is a late comer to the realtime audio world when
you consider the work of some prominent computer musicians :)
> >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.
>
I think it does - I don't think this is a requirement for dealing with
this type of data, however. Dropping integers can make things a lot
simpler without a loss of functionality (look at PureData compared to
Max).
> >> 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.
>
Paul, you are not understanding what I am saying. Here is some pseudo
code that might help:
class Osc {
public:
float tick() { return sin(phase); phase += incr; }
virtual void run(Buffer* out, int n) { for(i=0;i<n;i++) { out[i] =
tick(); } }
virtual void run_adding(Buffer* out, int n) { for(i=0;i<n;i++) { out[i]
+= tick(); } }
private:
float phase, incr;
};
At no point have I suggested inlining across plug-ins. In this example
tick could be a pre-processor macro (which I guess is what Steve does in
plain C). Please set your assumptions aside for a moment and read my
messages carefully and I will try to be more clear.
> there is no way you could inline all the code involved in that chain
> and expect to see sensible register allocation.
>
This is obvious and not what I was suggesting.
Karl
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 21:26:21 EEST