[linux-audio-dev] XAP again - channels, etc.

Andy Schmeder andy at a2hd.com
Sat Mar 22 14:08:00 UTC 2003


<quote who="Tim Hockin">
>> i know that. In galan it is the same.
>> But why should this difference be so clearly stated in the API ?
>
> Can you show me a nice API that makes the two feel similar?
>
> Controls: multiple datatypes, receive events in time-order queues
> Ports: are assigned buffers (possibly datatyped) of arrays of data

I've been partially involved with a project called Open Sound World for
some time (see http://osw.sourceforge.net/).  Yes, this is Yet Another
Modular Synth.  This is a project was part of the Phd thesis for a student
working at UC Berkeley CNMAT.  There is naturally a somewhat academic
mindset to the design used in this project, so bear with me...

In OSW, there is no distiction between 'control' data and 'audio' data. 
There is a very heavy emphasis on C++ generic programming and a rigorous
type model.  Blocks of audio data are classes of type Samples (actually
they are just typedef vectors of floats), control data is of class
'Float', 'Int', 'Boolean', 'String', 'List', etc.

The advantage of not specifying a difference is there is a vastly
increased power for runtime dynamicism.

There is a type called 'Any' which can be converted into any other type. 
Some objects have inlets and outlets specified as type 'Any', and the type
is changed upon connection with another object of specific type.  This is
useful for making a 'general purpose' object.  For example, named
Send/Recv pairs, List pack/unpacking, and control flow (FanOut, FanIn,
Switch/Gate).  So, there is nothing preventing us from packing up a list
of audio blocks and doing whatever we want from there.  In addition, there
are Open Sound Control objects which accept and transmit lists in the
patch; those lists might contain audio data, which means we can easily
send audio data over the network.

Additionally, it is trivial to implement alternative stream types
including audio streams running at different sample rates, different bit
types, etc.

Another point is that it -might- be possible to effectively utilize
SMP/parallelizm under this increased flexibility.  That is a current
research topic wrt. this architecture.

Systems such as the PD family and Jack have fixed audio types; this
enables you to approach audio processing a different way; i.e. the audio
graph ordering is precomputed by the engine.  You sacrifice runtime
dynamic routing in this case... but basically I think the idea is that you
don't really want it anyways. :)

So, there are downsides to having a fully dynamic routed graph:

1) you don't know how long the paths are in the audio graph, its
impossible to compute 'total latency' ahead of time.

2) you can't seperate the control and audio calculations; i.e. you cannot
decide to give one priority over the other.  There are arguements for and
against this point.  Any max user can sing a song about overdrive and
various insane scheduling hacks necessary to get control data to flow in a
timely manner.  If control data is subject to latency jitter, then what is
the point of having it at all?

3) performance; generalization *always* costs you something. 
specifically, I think modular synths suffer from having to do a of mixing
which could be avoided easily if you were coding straight C/C++.  Some of
these overheads are probably somewhat easier to mitigate using the
traditional audio-graph model (e.g. jack is able to mitigate cost in many
ways, by providing zero-copy buffers when possible, etc).


--aws

mailto:andy*a2hd,com
http://www.a2hd.com/




More information about the Linux-audio-dev mailing list