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: Jim Peters (jim_AT_uazu.net)
Date: Tue May 15 2001 - 19:31:04 EEST


Paul Davis wrote:
> 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.

Agreed. It's just that I don't have another term which emphasises the
notion of the "summation nodes" collecting the data from various
sources. This perspective from Tom seems very useful to me.

At an underlying level, the buffers look just the same, but I think
it's useful to hold onto any model that makes all of this more
comprehensible from a user perspective.

I think the word `pull' emphasises that the `summation nodes' are in
control of the mixing and buffer transfer, whereas with AES, the
plugins are in control of this.

Unless someone comes up with a more descriptive word for it, `pull'
will have to do, because we need to understand what we're talking
about.

Naturally, these `summation nodes' are just buffers managed by the
server, and the server can optimise things so that buffers are re-used
and copying stages are eliminated without disrupting the illusion of
the model presented to the user.

> 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.

Are you talking about using the same buffers for both input and output
of a plugin, or just re-using buffers `soonish' later in the graph ?
Either way, this is an optimisation to take advantage of caching,
right ?

This probably means that my pointer-passing optimisation (method 3)
doesn't look too useful, then, as it scrambles our ability to predict
which buffers will become free and optimise their use beforehand.

Jim

-- 
 Jim Peters                  (_)/=\~/_(_)                        Uazú
                          (_)  /=\  ~/_  (_)
 jim@                  (_)    /=\    ~/_    (_)                  www.
 uazu.net           (_) ____ /=\ ____ ~/_ ____ (_)           uazu.net


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

This archive was generated by hypermail 2b28 : Tue May 15 2001 - 19:49:52 EEST