Subject: Re: [linux-audio-dev] laaga: withdrawal/amendment of automated mixing proposal
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jun 18 2001 - 15:05:47 EEST
In message <Pine.LNX.4.21.0106181059020.1313-100000_AT_bellatrix.tat.physik.uni-tu
ebingen.de>you write:
>On Fri, 15 Jun 2001, Paul Davis wrote:
>
>> i have just realized a fundamental problem with the automated mixing
>> proposal that i made a few weeks back.
>
>Hey - I even stared to like the automatic mixing (from the users point
>of view) - also it would have made node suspension possible, without
>stalling subsequent nodes (they just get zeroes, or not mixed in output).
>
>[...]
>
>> or we do even more context switches, which doesn't seem too good of an
>> idea.
>
>Yes - you'd need to switch back to the engine for each node to node
>transition (you can optimize away some). You could embed the engine
>into the client side library (i.e. a distributed engine with its state
>in shared memory).
heh :)
i realized that a better way to do it is to drop direct access to the
port's buffer, and do this (to use the simple "through" client example):
int process (nframes_t nframes, void *arg)
{
sample_t in = audioengine_port_get_buffer (my_input);
sample_t out = audioengine_port_get_buffer (my_output);
memcpy (out, in, sizeof (sample_t) * nframes);
}
then the audioengine_port_get_buffer() function would somehow do the
mixing for us. i'm still working on how to do this. the problem is
that i don't like static limits on the number of port connections,
which means i use a list and not an array of them. but this list lives
in the engine's address space, not the clients, so a client has a hard
time getting info on all the connections, and hence cannot determine
whether and how to use zero-copy or mixing or whatever. i'm working on
some ideas for this. i may just have to abandon avoiding static
limits.
--p
This archive was generated by hypermail 2b28 : Mon Jun 18 2001 - 15:04:16 EEST