Subject: [linux-audio-dev] Ideas for AES/LAAGA/whatever (was Re: sound API libraries, servers, etc.)
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Wed Apr 25 2001 - 11:38:27 EEST
Kai Vehmanen wrote:
> > in my conception, the server makes available functions that the client
> > can use to read and write audio data to the audio hardware and also to
> > an internal bus network (so that data can be shared between
> > plugins). these functions work identically for real physical channels
> > or the busses.
>
> Ok, although I like to avoid using the term 'bus', the above seems correct
> to me. ...
If you're designing a new plugin standard, can I throw a few ideas
into the mix ? Here we go:
- Intelligent handling of silence. Many plugins can completely skip
processing a frame if there is silence on their inputs - they just
need an easy way to recognise that. In my plans the ->process call
(or equivalent) passes to the plugin an array full of pointers to
input/output buffers that the plugin should use. There is a
standard 'all-zeros' buffer which is passed whenever there is no
input or silence. The plugin can detect silence by simply comparing
pointer addresses. On output, it can either fill the buffer it has
been given, or replace the buffer pointer in the array with the
standard silent 'all-zeros' buffer pointer. A plugin that doesn't
want to understand silence can happily process all the zeros - until
someone cares enough about efficiency to fix it.
The advantage of all of this is that processing networks that
currently have silence going through them takes very little time, so
there is less need to keep turning them on and off. Also, something
like a delay or reverb plugin would still keep on outputting sound
for some time after silence reached its inputs, and then it would
finally output silence. By watching for this silence on the final
output of a network, a recorder would be able to know when to stop
recording to disk at the end of a song (say) instead of having the
sound cut off before it has completely faded.
- Upgradable control inputs. Control inputs often have constant
values over the length of a frame, which makes processing more
efficient. However, when control inputs change, if they change in
steps you often get unpleasant side-effects. For instance, if it
is an amplitude control, and it changes at the frame rate of 200Hz
(say), then you are going to generate a 200Hz ripple, which is
definitely audible. If you think you can improve this by increasing
the frame rate, you just shift the frequency of it. The only answer
to this is to change control inputs smoothly, at the sampling
frequency.
The upshot of this is that control inputs need to be able to switch
between constant values and sample-rate values from frame to frame.
If a plugin author chooses not to handle this, well, so be it - the
plugin can take the first value of a sample-rate change, and we'll
live with the distortion until someone improves the code.
I know how much this feature is necessary from the coding of my
utilities SBaGen and `rhybag', and also from experiences with
CSound. So many people code something up in CSound, discover that
it sounds crap because of their frame-rate, then up the frame rate
to compensate - to the point where they lose the speed benefits of
processing in frames.
- Command-string control ports. Strings are good - you can encode
almost anything as a string. Commands to a plugin can be easily
sequenced as part of a song or mix-down (the sequencer doesn't have
to understand what the strings mean, just store them, and feed them
to the plugins at the required moments). As a general type, it can
cover a huge amount of stuff. If you're worried about the overheads
of parsing strings, remember that these are likely to be coming in
at the control-rate or slower. Worst case, we could give the plugin
the opportunity to precompile command-strings before a sequenced
song/tune starts. The flexibility this buys you is well worth it, I
think.
I was thinking of creating a modified LADSPA to handle these extra
features (I like the LADSPA approach), but I've got other things to
deal with at the moment. If any of these grab you, feel free to
incorporate them into your AES/LAAGA/whatever thing.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Wed Apr 25 2001 - 12:11:48 EEST