Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Thu May 03 2001 - 18:36:55 EEST
On Thu, 3 May 2001, Paul Davis wrote:
> IMHO, these are better written as:
> void (*read_from_channel) (channel_id_t channel,
> sample_t *buf,
> guint32 nsamples,
> guint32 offset);
Btw; as a coding style issue, I like to avoid using typedefs. Ie. if I
need an integer, I use 'int' or 'long int', if I need a float, I use
'float' or 'double'. This makes my intention clear. But no worry, I'm not
religious about this. ;) But I do think that excessive use of typedefs can
cause unneeded confusion, and especially at early design phases. 'int' is
always an integer number, but 'id_t' can be anything from a 'char' to
large C struct or a function. In the worst case, specifications are
written and approved, but then at the implementation phase we realize that
we've had drastically different opinion about what 'id_t' should really
be...
> the channel_id_t allows encoding of different types of channels (aes
> supports hardware, internal bus, network).
Hmm, my idea was to hide the meaning of channel ids from the clients. Ie.
client requests for two output channels, and server gives two integers.
It's up to the server to give a meaning to these numbers. Ie. some server
might give totally random ids (although not necessarily very efficient).
> void (*write_to_channel) (channel_id_t channel,
> sample_t *buf,
> guint32 nsamples,
> guint32 offset,
> gain_t gain);
[...]
> the offset is needed to allow internal sample-accurate event
> processing (since the reads/writes may be divided into several chunks
> to cope with intra-block events).
Btw; One critical thing missing from my draft callbacks is setting the
blocksize. Anyway, what if client issued multiple write_to_channel()
calls:
write_to_channel(ch_id, buf_base, n1)
write_to_channel(ch_id, buf_base + offset1, n2)
write_to_channel(ch_id, buf_base + offset2, n3)
... and for each process(), 'n1+n2+n3 == blocksize' would have to apply.
> the gain for writing is extremely efficient, since it avoids an extra
> data copy when deliverying data with non-unity gain.
Isn't it enough that the server can do this (it knows how many clients are
registered to one channel)? In the end it's a question of who controls
channel gains. Currently in AES, Ardour has the gain information so it
needs to pass it as a argument to AES. But you could have the channel-gain
information on AES side... (AES could also have a GUI).
>> - common transport functionality (prepare,start,top) which can
>> be triggered by any of the clients, or the server
> don't call this "transport" please.
[...]
> you can stop the engine itself - this simply means that it doesn't
> ever call the plugin chain. in aes, stopping the engine actually
> closes the audio interface. i suppose that notifying plugins that we
> are stopping for a while is not a terrible idea, though i haven't
> found it necessary so far.
Ok, possibly not such a good idea after all. What I was thinking was -
let's take an example, we have three GUIs - one for server (handled
outside of LAAGA) and two clients GUIs running in separate threads. Now my
idea is that it would be possible to start and stop processing from all
GUIs. For instance if processing is stopped from the server GUI, server
calls client->stop() for all plugins and stops calling the
client->process() callbacks. The same happens if any of the clients call
server->stop().
From user's point of view, this would seem quite intuitive. The different
apps (= GUIs) would just be in complete sync. No matter where you push
'start' or 'stop', all apps would react. Of course the LAAGA server would
still be controlling the whole thing (= actually calling the callbacks).
But although a nice sounding idea, there are quite tricky problems
involved (ie. how would the client actually call server->stop(), and from
which context?). So at least for now, you can probably forget the
server->prepare/start/stop ...
As for client->prepare/start/stop, these are probably good to have,
although many apps won't need them. Possible uses:
prepare:
- start data prefilling in the low-priority process
start:
- notify the client GUI that processing has started
stop:
- stop prefilling and notify client GUI
... but in the end it's up to the client to decide how to use these.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 00:29:28 EEST