To: Noel B: DAW (SONAR) Architecture...Block Diagram

[Sure hope Noel's around this weekend]…

Noel Borthwick…

(& DonM, UnderTow, DaveClark, aj, altima_boy_2001, et al)…

1) Back in May, there was a DonM thread running entitled: "The Ultimate Bit Depth Post", in which a flow chart of sorts was assembled to show resolution/signal flow thru SONAR's various code sections. I ran across it the other day; & as some of you may know…I've been attempting to gain my own understanding of SONAR's internal > output architecture. Based on a reply in Don's thread from Noel B…I decided put my own Block Diagram together:

[Note that I didn't include resolution in the drawing, since we have 64-Bit DP FP from end to end anyway (& the output inquiry will come later.)]

So…Noel…based on what you (or anyone) knows (or can tell me) regarding native DAW Architectures (& specifically SONAR in this case)…how does this look:




2) As part of that discussion (& also part of my own recent thread), UnderTow & others were also talking about SONAR's output to the DAC. The device drivers to my audio interface (Lynx Aurora8/AES16) can receive a "32-Bit (integer) container w/ 24-Bit data". If Noel could tell me exactly what SONAR sends out to the Lynx in this case, I would be eternally grateful. Is it a 24-Bit word with padded zeros as UnderTow suggests…or is there more to it? (& if it is a padded signal…why???...since the very next hardware stage is the DAC, which can only receive 24-Bit integer…i.e., why the need for empty data w/ no hdwe. processing occurring at that point?)

Thanks much,


mark4man

Dell Dimension 8250 / Windows XP
Intel 850E Motherboard/Chipset
Intel P4 2.53GHz CPU (512 KB L2 Cache, 533 MHz FSB)
1024 MB PC1066 RDRAM
Maxtor DiamondMax 9+ 80GB Secondary HD / Single Volume (Audio Data)
Lynx Studio Aurora 8 / AES16
Universal Audio UAD-1 DSP Powered Plug-In System
KRK Rockit RP-8 Studio Reference Monitors
SONAR5.0.2
WaveLab 5

I still want to know, definitively, if the Console Strip EQ is exactly the same as the Track View EQ insert point. :-)

Lookup Signal Flow in the Index of the online help for a link to the diagram that tells all.

Mark:

Nice post and diagram. I am interested in the word length issues associated with every stage with regard to bit bridge and the like. VSTi's as well in the mix, so let's see where this one goes.

-D

DonM...

You're thread made me realize I was going in the right direction...so some thanks should go back to you as well.

And yeah...I'm also interested in those issues...but I want to start off by making sure I have the code block structure correct; & then focus on Output first. Here's hoping we get some heavy hitters.

Thanks again,

mark4man

I still want to know, definitively, if the Console Strip EQ is exactly the same as the Track View EQ insert point. :-)

Not THAT again...

Mark:

There is another thead I posted in yesterday that was dealing with the Audio Engine. As I read the thread I sat there thinking if one of my students in class asked me to describe the differences between the audio engines in different DAW's what would the differences be (BTW this is how I think - I make up the questions before they are asked).

First off - I'm not even sure what an audio engine is 'anymore' - maybe I never knew in the first place but the more I know the less I know..

Second. One way they for sure could be different is signal path/flow and how the wordlength may be affected. BTW did you include the external insert option in S7 in your diagram? - Keep in mind the whole D2A and A2D through your soundcard and issues associated with that must also be considered.

Almost too much for me to realize without some pretty deep guidance from the software engineers.

Again, nice question. Not sure we can get a thorough answer without traveling to Boston for a few weeks.

-D

Sligtly off-topic, but still want to know why the PRV scrub tool bypasses the midi FX bin...

SilkTone

bounce (to bring up for Noel)

[hope he's in today (Columbus Day.)

mark4man

Mark:

He and the team are probably recovering from AES lag....

-D

..never mind me.
I'm just climbing aboard (via checked "Notify me via Email.." box) to see where this excellent topic goes.

Hi Mark,

You have seen the SONAR signal flowcharts in the help file right? Search for "Signal Flow" in the help file. Those diagrams actually have more detail than yours. :-)

In SONAR and presumably any DAW, there are conceptually 3 components.
1. Audio sources (audio from tracks, input channels, synth outputs)
2. The signal flow/bussing topology (outputs, sends, buses)
3. The hardware

A simplified signal flowchart looks like this:

Audio sources ===> routing topology ===> Hardware

During playback there is a pump 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 (1) is upconverted to 32 or 64 bit float before entering the bussing topology. It is upconverted to 32 or 64 bit float depending on the setting of the "64 bit double precision" setting in Options | Audio. We do this so that we can have a uniform bit depth while mixing and processing plugins, avoiding the cost of conversions. This float 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 buses in SONAR, except that they are internally created and tied to available hardware outputs. In fact in SONAR's mix engine, internally everything routes through a bus, including output from track's 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 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 downconverted to the target bit depth resolution (as set by the Audio Driver bit depth setting in Options | Audio | General) and dithering kicks in (if enabled).
This is the time where all the hardware specific stuff is applied. e.g. 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 all done for processing efficiency from the driver's point of view not for audio quality.

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

Hope this answers your questions.

Noel...

Thanks a million !!!

I wasn't necessarily interested in the audio track flow chart...knowing where that is & mostly understanding it. I was more interested in how SONAR implements that signal flow, via code sections...the architecture of the program (the 'topology', as you say.) And I used terms familiar to mixing consoles to make better sense of it all structurally. But you've certainly given me (& everyone) a wealth of information; & I'm already beginning to understand the scheme of things based on your (very informative) mapping.

I'll now go back into Illustrator & rearrange the diagram (& re-post a revised one.) But first...I need a few minor clarifications from your explanation:

1) In #1, I am assuming by 'input channels' you are referring to hdwe. inputs; & by 'synth output' you are referring to soft synths (as, for example, coupled to the hdwe. input in the previously mentioned flow chart)?

2) In #2, I am assuming by 'outputs' you are referring to track outputs? [Sends & busses being self-explanatory here (especially in light of the great description you gave on SONAR's internal bussing !)]

3) In all of your dissertation...you never mentioned where exactly plug-ins are tied in. We obviously have clip bins & track bins & bus bins...& on the track side, you detailed the resolution up-conversion, in order to lay out the case for uniformity of mixing/processing...so I would have to assume that up-conversion takes place prior to the clip bins (& that those clip bins also fit within the bussing topology)?

[This almost makes me want to return to my channel strip mentality (in understanding SONAR's architecture), because...it almost sounds like...each audio source undergoes upward conversion (analogous to input Z) prior to entering each internal bus (analogous to channel)...is signal processed (Volume, EQ, Pan)...FX/dynamically processed [Effects Insert (Send/Return)]...& then routed to a stereo bus. And you said yourself that, internally, everything is bus (channel?) routed.

But this brings up my last question. 4) You said that the "float data flows through the bussing structure and is summed at the same resolution at each bus input". Did you mean to say bus outputs? Because you went on to say that the result of all bus outputs is received at the master bus; & I'm thinking that the summing has to occur at the output of the internal bus, prior to routing to the master bus.

Thanks again...this is all very much appreciated,

mark4man

Noel/Mark:

Great stuff. I am interested now how the new S7 hardware insert fits into this audio chain - it seems like it functions as a micro version of the whole process?

-D

Mark,

Wonderful discussion! Thanks for starting this thread.

And, of course, thanks to Noel and others for also contributing.

Regards,
Dave Clark

Thanks Noel,
mike

OK...

This is about as good as I can do tonite (being dog tired)...in superimposing Noel's accounting of SONAR's architecture over the flow chart...

[&...as to that chart...it's never included virtual busses...so the following may be more useful in block diagram land]...(man...I need rest):



& Noel...this one is based on my assumptions to the questions in the prior post...so it may be a bit out of whack if your answers to those are different.

Thanks again,

mark4man

Don there is a nice signal flowchart in the help file for the external insert. Basically this is a filter with 2 inputs and 2 outputs that are cross wired. The first input is wired to the hardware output send and the hardware return patches to the second input, which is internally wired to the EI primary output.

ORIGINAL: DonM

Noel/Mark:

Great stuff. I am interested now how the new S7 hardware insert fits into this audio chain - it seems like it functions as a micro version of the whole process?

-D

Its difficult to explain all of this succinctly in a few paragraphs or diagrams, but I'll answer your questions. There is a lot of complex stuff under the hood.

In 1, I was referring to soft synth outputs or synth tracks in SONAR terminology. These are outputs from synths from the synth rack.

In 2 I was referring to the framework of connections from the outputs of tracks or buses to the inputs of other buses in the project. Remember a track is very similar to a bus from a signal flow perspective in SONAR. The framework or topology as we call it, is like a giant user configurable hardware mixer that can be dynamically rewired by interconnecting bus to other buses.

Regarding 3, plugins live in effects bins. Every bus in SONAR has an associated effects bin. A bus in SONAR is a complex multi-in/multi-out object that aggregates a mixer and an effects bin. Track effects reside in internal track bus effects bins and user bus effects live in the associated bus effects bin. A SONAR bus is sort of like a meta channel strip in hardware mixer terminology. It handles vol, pan, summing and effects.
Additionally every audio clip has an effects bin that houses clip effects. During the signal flow though buses, 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.

All upconversion to float takes place prior to clip effects and the bussing framework.

>>You said that the "float data flows through the bussing structure and is summed at the same resolution at each bus
>>input". Did you mean to say bus outputs

No I meant inputs. 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 whole thread reminds me of how smart I am not.

Show me a place where the CTO of Digidesign or Cubase or Logic answers technical questions at length like this on a forum at 9:00 at night and they might have a fighting chance against Cakewalk in the long run.

I can't think of a single large company in the business that pays anywhere near this much attention to users.

Kudos for all your hard work Noel!!!

Noel...

You absolutely are the best; & it's like tunekicker said...where else in the industry save for 268 Summer St. can assistance such as this be had? & this is truly phenomenal, for me (& I'm certain others), I can tell you...you cannot begin to realize how much this has helped in my understanding of the program.

So...in pouring over all the details night after night...the following should represent the final draft (& then I have one final minor question on the output...& that should wrap it up):





Q: On the 32-Bit Container/24-Bit Data output to my Lynx AES16 device drivers...(& I'm assuming those drivers request the 24-Bit data packed Left Justified in a 32-Bit word)...in using their ASIO drivers, those data packaging selections are not present in SONAR, as they are when utilizing WDM's. So would left justified continue to be the default w/ ASIO?

Thanks again...for all your help & all the informative answers,


mark4man

bounce for Noel...

ORIGINAL: mike_mccue

I still want to know, definitively, if the Console Strip EQ is exactly the same as the Track View EQ insert point. :-)

Well, I am not Noel, but I assume that this is the case, as right-clicking on the console strip eq plot and selecting "show eq properties" brings up the Sonitus Eq plug-in, as they say, large as life and twice as angry ... or am I missing some humour behind that smiley face of yours?

Unlike WDM, ASIO has an explicit API (ASIOGetChannelInfo) to query the driver for this sort of info so there is no need for the end user to specify this.
This API returns an ASIOSampleType describing the format of a sample. I'm not sure what the Lynx drivers report but its probably one of ASIOSTInt24MSB, ASIOSTInt32MSB24 or ASIOSTInt32LSB24.

ORIGINAL: mark4man

Q: On the 32-Bit Container/24-Bit Data output to my Lynx AES16 device drivers...(& I'm assuming those drivers request the 24-Bit data packed Left Justified in a 32-Bit word)...in using their ASIO drivers, those data packaging selections are not present in SONAR, as they are when utilizing WDM's. So would left justified continue to be the default w/ ASIO?

Noel...

Commentary on the diagram...?