[linux-audio-dev] signal flow in Quasimodo

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] signal flow in Quasimodo
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to syys   23 1999 - 11:08:22 EDT


Juhana had written privately to me:

>About that earlier mail on the flow algorithm: I indeed were looking
>for the info how the signal is made to flow. Particularly I'm interested
>in how a feedback loop is handled. Simply setting nodes and initially empty
>arcs doesn't work because a node might get input from a second node which
>gets input from the first node.
>
>I solved the problem by having delay elements to output their delay samples
>to their output arcs. Only generator elements and delay elements have outputs
>without getting any input first.

this is essentially how Quasimodo (and Csound) work as well. but to
clarify:

1) all output is written to a staging area via the opcodes out, outs,
   outq outh, etc. (these write 1, 2, 4 and 8 channels
   respectively). Each of the "out" opcodes sets a flag saying that
   output has been produced. At the end of each DSP control cycle, if
   the output flag is set, the output is sent to the DAC; otherwise, a
   control-cycle's worth of silence is sent.

2) all input from a hardware source is read into a staging area from
   where it can be retrieved by the opcodes in, ins, inq, inh etc
   (analogs to the "out" series).

   all input from a soundfile is requested explicitly by an opcode.
   input files are shared across all modules and opcodes, and each may
   be reading from separate areas of the file.

3) delay lines and other opcodes needing their own signal flow do something
   described in Csound as an "auxilliary allocation". That is, their closure
   contains a pointer like this:

              AUX *delay_line;

   and during the constructor/initializer for the opcode (run at
   "i-time") a function is called to allocate memory and store the
   location in this pointer. the engine also notes the allocation, and
   associates it with the module. when the module is deleted, the
   memory is deleted too - its basically an internal heap system. The
   opcode can do anything it wants with this memory - it is ignored to
   the "engine" except with regards to allocation and cleanup. this is
   how delay lines work.

   Quasimodo is mostly identical: we just use a more C++-like syntax
   and semantics. Its called DynamicMemory, and the C++ compiler
   ensures that it gets cleaned up instead of the engine
   code. Quasimodo also has some hooks to allow allocation of enormous
   disk-based delay lines, so that we do delays of several minutes if
   necessary. I'm an experimental musician :)

4) there is no way to control signal flow ordering except through the
   alphanumeric sorting by name of modules in the DSP work queue. that
   is, if you have a signal generator named "xxx" and a delay line
   called "aaa", then on the first control cycle, only silence will
   emerge, because the signal generator will run *after* the delay
   line. there will be a similar overrun at the end, unless the end
   is caused by deleting the generator module, which instantly sets
   its outputs to zero.

   This may change at some point.

Another matter: do you have any material that you think would be good
to include in my "Why Linux?" brochure for AES this weekend ?

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST