Click here for MoonBits.com SONAR Informationals

SONAR's code architecture consists (conceptually) of three major sections:

1) Audio Sources (audio from Tracks, Input Channels & Soft Synth Outputs.)
2) The Signal Flow/Bussing topology (Busses, Outputs, Sends.)
3) Output to Hardware.

To quote Noel Borthwick, Cakewalk CTO: "During playback a pump is running that continually services the audio sources; and pushes audio through the signal flow all the way down till it reaches the hardware".

At the audio source level, mixed bit depth (16/24/32/64 bit) audio from tracks is up-converted to 32 or 64 bit floating point precision before entering the bussing topology. [This upward conversion is dependent upon the "64-Bit Double Precision" setting in Options > Audio.] Cakewalk code designers do this in order to have a uniform bit depth environment for mixing and processing plug-ins (& thereby avoiding the cost of additional conversions.) This floating point data flows through the bussing structure and is summed at the same resolution at each Bus Input.

Finally the result of all Bus Outputs is received at the Master Bus level. Master Buses are just like normal user (virtual) buses in SONAR, except that they are internally created and tied to available hardware outputs. [In fact, within SONAR's mix engine…internally…everything is routed through a bus, including output from tracks and synths (although these buses are not user visible.)]

At the Master Bus level all inputs are summed and then sent to a rendering component, which is responsible for delivering the final mix to the audio hardware. At this level, the audio is copied to the hardware output buffers. Only at this time is the audio down-converted to the target bit depth resolution (as set by the Audio Driver bit depth setting in Options > Audio > General.) Dithering is applied at this point (if enabled.) It is also at this time when all hardware specific functionality is applied…e.g., hardware device drivers expect audio data packaged in different ways. Some expect an interleaved stream of audio with data for each hardware output packed end to end…some expect 24-Bit data packed left justified in a 32 bit integer…and some expect it packed right justified. [This is implemented for processing efficiency from the driver's point of view not for audio quality.]

Once the device driver receives a filled buffer it is delivered to the DAC. This completes a single pump cycle and the process repeats.

Important Concepts to Remember:

Component 1:
Audio Clips are the pre-recorded audio data that make up tracks. Input Channels are the hardware inputs, for recording. Synth Outputs refers to soft synths (as, for example, coupled to the hardware input on the manual's audio track flow chart.) This is synth track data, from synth outputs in the Synth Rack.

Component 2:
This component consists of the framework of connections from the outputs of Tracks or Buses (including Bins & Sends), to the inputs of other Buses in the project. A Track is very similar to a Bus in SONAR, from a signal flow perspective. The framework, or topology as we call it, is analogous to a giant user configurable hardware mixer that can be dynamically rewired by interconnecting bus to other buses.

A Bus in SONAR is a complex multi-in / multi-out object that aggregates a Mixer Component and an Effects Bin. Track Effects reside in internal Track Bus Effects Bins; and User (Virtual) Bus Effects reside in the associated Bus Effects Bin. A SONAR Bus could be described as a meta channel strip of sorts, in hardware mixer terminology. It handles signal processing (volume, pan, EQ), summing and effects processing. Additionally, every Audio Clip has an Effects Bin that houses clip effects. During the signal flow though the bussing structure; audio buffers are pumped serially through every effect in the associated Effects Bin. Clip Effects Bins are basically serviced when the associated track data for that clip is read at the audio source level. They are special in the fact that they live outside the bussing framework but rather at the audio source level.

[Please note that all up-conversion to floating point precision takes place prior to Clip Effects and the bussing framework.]

Summing occurs after all Bus Inputs (routed from other Tracks or Bus Outputs) are available; and is handled by an Input Mixer. The summed input stream is then pumped through the Effects Bin; and then dispatched to the Bus Output and Sends. This means that summing at the Bus Input is handled internally (by SONAR), via the Mixer Component; and externally (by the Effects Plug-In) at the Bus Output.

Component 3:
This component functions as per the above summation (Master Bus.) It is configured as per the signal flow of a virtual bus, but coupled to the Rendering Component (which is in turn coupled to the hardware Device Drivers for physical output) or rendered to file. Summing at the Master Bus is handled internally (by SONAR.), via the Mixer Component.