Subject: Re: [linux-audio-dev] back to the API
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 17 1999 - 01:06:17 EDT
[ ... missing reply ... ]
>What's the date/time of that post, in case I'm not thinking about
>the right one?
note sure precisely, since i don't keep records/copies generally, but
it was my reply to your reply to my post of Tues Oct 12 1999, 12:18:13
EDT (subject "big picture, for a moment").
>1) Huge block transfers
[ ... ]
>2) Variable data (audio) buffer size
[ ... ]
Gregory Bateson once defined information as "any difference that makes
a difference". as i started writing an implementation of the system
we've been talking about so far (yep, rapid prototyping works better
for me than text sometimes), it seemed very clear to me at least that
events can be beautifully defined this way if you are willing to
exclude any data streams, including audio and "huge block sizes".
that is, an "event" is a notice that something has changed. the notice
can either be a delta from the old state, a new state, or a notice to
increment or decrement (which can have type-specific semantics).
[ in this system, a GUI would lookup the target ID of a plugin's
parameter, associate with a widget or whatever, and then whenever
something changed because of user interaction with the GUI, the
GUI would send an event saying "target ID has changed, the
{delta,absolute value} is XXX". (Note: working in delta's
is probably a good idea, when i think about some of the
horrible aspects of some automated mixing visual+physical UI's)
the plugin, when it noticed the event, would map the target ID to
its own parameters (*probably* represented by some variable in
memory), and perform the adjustment(s) as it saw fit.
]
what would it mean to say that the "audio" has changed ? thats hardly
a difference that makes a difference! audio is really a data stream,
not a series of events. you've already demarcated them linguistically,
and suggested that a plugin would get audio via at least one audio
port "which is not the same as its event port" (my wording, your
intent, i hope). this strongly suggests to me that its a mistake to
consider these to be the same thing. look at two of the most salient
differences:
1) data size: audio (N samples per call to process (); likely
to be N >= 32 ... 128 bytes for RT; non-RT
processing might go way higher ... 4KB ?)
event (with my Bateson inspired idea, about 24-32 bytes)
2) data rate: audio (MB-GB/sec, continuous)
event (often zero, typically bytes/sec, very intermittent,
typically bursty)
i am therefore not convinced that these two very different entities
should be considered the same thing at all.
what about jaroslav's example of an instrument request ? well, the
wording is interesting. "request" ... this is not a notice that
anything *has* changed, its a notice that someone would like something
*to* change. if you had to cast it into an event, it would look more
like "XX has placed a request with YY". that is: the state of some
"request" parameter has just been changed. there should be, as you get
close to concluding, some other way to move whatever data is
associated with the "request" parameter from the one place to another.
this hints at one problem with my Bateson inspiration: strings and
other things where "state" is not a scalar. i am trying to think about
this. i really don't want a silly limit on string/array size on the one
hand, and on the other, a ridiculous consumption of unnecessary memory
if an implementation uses pool-based memory allocation (which mine
will/does).
one possibility is that things needing to work with non-scalar data
request a piece of global memory (regular memory for threads, shmem
for processes), and then work with that memory as the storage for the
non-scalar. the event would just contain a void * then, pointing to
the global memory. this has its problems, not least of which is
atomicity of the contents of the memory. if the plugin has been told
that, say, a string value has changed, but then the string changes
again before/while its looking at it, this is, uhm, not good :)
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST