Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 15 2001 - 17:41:12 EEST
>Taking the simplest approach, the cost would be the same as in Paul's
>model. In AES the plugin writes to its own internal buffer, and then
>calls write_channel() for each of the busses it needs to add to. If
>instead we give the plugin a buffer to write to, then we (as the
>server) can do the writing to busses for the plugin. This is exactly
>the same amount of copying, but it gives the advantage of enabling
>this `pull'-oriented model.
I agree entirely with the analysis. However, I'd stay away from the
terms "push" and "pull", since neither of them capture what's really
going on. With any of the models under discussion, we are telling the
plugins that its time to do whatever it is they need to do. What
happens before and after that phase is not something the plugins need
to be concerned with, and hence whether they are actually "pushing"
data by writing it to their output buffers, or its being "pulled" from
them, is really inconsequential (and invisible).
>This can be optimised further in a few special cases of connections
>with gain==1.0, cutting out an additional copying step, but what
>exactly we can optimise depends on whether we choose run()-style or
>run_adding()-style for our plugin outputs. This optimisation makes no
>difference to how the plugin behaves, because all it has to do is
>write to the buffer it has been given.
Note that from my experiments with Ardour last week, it can make a
*huge* difference if you can re-use the buffers as much as possible. I
got an 8-10% performance improvement by using just one set of buffers
(and in fact, in my tests only a single buffer of the set was being
used) for every chunk of internal processing by ardour's internal
objects. Clearly, there are some graphs where this doesn't work, but
if its possible to arrange for this, its a huge win.
--p
This archive was generated by hypermail 2b28 : Tue May 15 2001 - 18:01:43 EEST