Author Topic: My checklist for a DAW deployment  (Read 14606 times)

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
My checklist for a DAW deployment
« on: November 07, 2017, 11:30:56 AM »
I have composed my personal "check list" for computer running Sonar.
Some problems I hit more then once, and I hope the list can avoid that for me (and may be other users ;) )

Note: many statements are IMHO and I do not pretend to be complete nor right. Also I put no references since I have the feeling all that is "common knowledge". Feel free to comment or PM me in case you disagree.

Hatstand (Dave) from CW forum has translated some of my thoughts into English and also contributed to the content. Many thanks!

Computer optimization
  • Use quality components, especially check PSU and cooling
    Spoiler for the explanation:
    Impact: can greatly effect the stability and the noise level.
    Severity: can make the system unusable for real-time audio (f.e. default coolers can be unable to keep CPU in Turbo frequency permanently).

    When looking to purchase a new computer, the CPU, the motherboard chipset and major features are usually specified and all computers with the same numbers, from "unbranded" up to "studio optimized" will have exactly the same CPU chip. But the rest of the information is usually omitted from the specification.
    PSU: While it does not contribute to the system performance nor features (and so "low end" PCs normally come with the cheapest possible), it is a very important component. Unbranded (and as tests show, some branded) PSUs are sometimes unable to deliver enough power so if you see “800W PSU”, that does not automatically mean it is fine for a 300W system. There can be unusual voltage changes, bad filtering for changes in the net, loud noise from the cooling, inefficient power consumption, incorrect cabling options, etc. An otherwise fine system can be noisy, unstable and even physically killed by bad PSU.
    Cooling: Office desktops and most Notebooks are designed to work in "power saving" mode most of the time, with short periodic "burst" activity (boot, open application, calculate something, etc). As with a PSU, the cooling does not improve marketing parameters for office computers and so most of the time it is cheap and just covers the average use case.
    As mentioned later, during real-time audio, the computer will need to be in "performance" mode, consuming significantly more power than for an "average user". So, it makes sense to look at "gaming" cooling solutions, since that is the only other big user group which has the same demand (for desktop/notebook PCs). But note one important difference, gaming cooling has advantages when over-clocking but not in the noise level it produces under nominal conditions. When everything around is "exploding", the last thing which the gamer considers is the fan noise. Fortunately, gamers from time to time browse the Internet and like silence during that periods. So more "top-end" gaming cooling solutions are no longer loud without load (cheap gamer cooling still sacrifices silence for the price).
    A warning about fan-less computers: modern powerful computers produce ~200-300W heat. It had to be "exported" from the case, with or without a fan. So, fan-less systems are usually under-powered. Also, many of them are not really noiseless, many electrical components produce hi-pitched noise and it can be louder when the temperature is high.  This is unavoidable in a fan-less system working just on air natural convection.
    A warning about server cooling: because of the larger number of cores, server solutions can be considered instead of desktop for audio production. Note that servers are designed to work in a dedicated server rooms, with additional room cooling and without people around. Manufacturers do not think at all about the noise level, but more importantly some server cases REQUIRE water cooled rack installation.
  • Choose right connection for your audio hardware
    Spoiler for the explanation:
    Impact: badly connected audio interfaces can trigger all types of glitches.
    Severity: from audio skips/drops up to an unrecognized device.
    For your particular audio interface(s), check the exact recommendation for the best way to connect it. The only general recommendation is to share as little as possible with other devices in the system. So, try to avoid USB extenders/hubs but do not accept even this recommendation verbatim, some interfaces can work fine on 10m+ USB hubs (not all and sometimes an extra power supply is required, but still).
    The general recommendation to use a specific chip manufacturer is normally NOT sufficient, i.e. when you are looking at a Firewire controller and you read that "TI is better than VIA", it is not always a
  • Check for BIOS updates.
    Spoiler for the explanation:
    Impact: can solve already known problems with the motherboard
    Severity: especially with self-build PC, outdated BIOS can make the whole system from unstable up to unable to boot.
    Although people buy motherboards to match the chip, it is worth noting that whether you buy a complete system or individual components, it could have been on the shelf or in a warehouse for up to 6 months, so the first thing you should do is update the BIOS. The first release of boards with bleeding edge technology is normally in a hurry, before everything is broad tested. In that case BIOS updates are released a short time after, sometimes several in a row.
  • Disable C states,  EIST, SpeedStep, “Cool and Quiet” and other power saving options.
    Spoiler for the explanation:
    Impact: can boost system performance and reduce system latency, avoiding the interface instability with low ASIO buffer size and audio clicks/pops. Severity: depends from the hardware and Windows settings.
    Note: most notebooks and some desktops are not build to work with "full power" all the time. Disabling all power saving option permanently is not possible in this case, the system will be too
    hot and/or too loud. You can still try to disable them in BIOS to test they are infuencing latency, except C states that also can be done with software (see Latency Monitor section).
    Modern CPUs can be put into low power consumption modes using several technologies. That is normally controlled by the software (OS), but it can happened disabling an option in BIOS works more reliable. I have decided to keep C1E disabled, while re-enabled EIST without problems. My CPU fan is the only not dead silent fan in my old computer... EIST allows clock down the CPU frequency by Windows power plan (see laters).
  • Disable all build-in components you do not need
    Spoiler for the explanation:
    Impact: can free up some resources. Severity: low, build-in components normally does not consume much resources nor interfere with dedicated audio interfaces. But under some conditions that reduction can improve the performance and stability, especially on low end systems.
    Each enabled component (IDE interface, audio interface, etc.) takes some physical resources (addresses, interrupts, etc).  But more important is the existence of drivers in the OS, which take some CPU time, RAM, required updates. If the hardware is disabled, all that is not needed. A clean table does not normally impact your productivity, but why not take away all that old, dusty and useless papers from it? Once in a while an important document can be lost otherwise.
  • Disable over-clocking, note that some systems have it on by default
    Spoiler for Hiden:
    Impact: can increase the system stability, in case you observe some problems with it. Severity: over-clocking can make system unusable by producing a wide spectrum of glitches, it always heat over-clocked components more and so reduce the life-time and increase the noise.
    Unlike servers components, most "hi end" desktop components are gamers oriented. That is the primary user group for such components, and several more FPS in a shooter is used as a marketing strategy. While demanding games are called "real-time", several ms jitter is never a problem as well as some "wrong" pixels in one from 100 pictures per second. Global network latency is more then 10ms, human reaction in a "battle" is even slower. What is achieved in a game by over-clocking is more detailed and/or smooth moving picture. For audio applications even a very small jitter can produce an audio buffer under-run and so from pops/clicks up to audio driver crash. So the stability has top priority. Extra power consumption can also be problematic because the cooling system start to produce more noise. 
    In case nominal computer power is insufficient for demanding project, the over-clocking can be used as the last option before upgrading the system. But with extreme care, taking described consequences into account.
  • Check/adjust settings for gaming RAM
    Spoiler for the explanation:
    Impact: can lightly increase general system performance. Severity: as long as you use the manufacturer specification, there should be no problems.
    Many hi quality RAM modules are prepared for over-clocking and checked to perform well with better parameters the nominal (I mean timing numbers, not upper frequency thought for over-clocking). Checked timing numbers are mentioned in the module documentation, but the motherboard can still use nominal settings by default. The difference can be significant, especially when the system is not over-clocked in general. If there is no voltage/frequency increase, adjusting these numbers should not significantly change the power consumption (so no more heat, means no more noise).
« Last Edit: October 17, 2019, 11:56:28 AM by azslow3 »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
Re: Tips for computer optimization to run Sonar
« Reply #1 on: November 07, 2017, 02:55:26 PM »
Windows optimization
  • Use High performance power plan
    Spoiler for the explanation:
    Impact: possible dropouts, device disconnects, unresponsive system. Severity: depends from the hardware
    There are many options in the power plan to save energy, most important for real-time audio production:
    • CPU frequency. Min/Max should be set to 100%. Changes in frequency can glitch real-time processing, the load from DAW can be considered too "low" by the system, modern CPUs tend to be slower then 10 years old CPUs when in power saving mode to consume less power. You can see (close to) current frequency in the Windows Task Manager
    • USB power saving. Bad when you have USB audio interface.
    • Disk power saving. It takes time to continue working with disk after it was suspended.
    There are several utilities to fast switch the power plan if your computer is not DAW dedicates. F.e. for Win10:

    Interesting that by default many fine tune parameters are not visible in the power plan UI. You can un-hide them with (that is .bat file). Be prepared to deal with HUGE number of new parameters. Note, this file just let you see settings power plan use. It is not changing anything, you will have to do this manually. From other perspective: these parameters are used, even if you do not see them. In case you was wondering why changing some existing power plan to exact values you know was not producing the same result as setting these values in another power plan, you know the answer now ;)

  • Your DAW is not a game
    Spoiler for the explanation:
    Impact: win10 has introduced "gaming mode". Severity: when Sonar is running in gaming mode, many strange things was observed.
    When it was introduced (2017), Windows was in the gaming mode itself by default. But there was a switch to turn that off.
    In the October (2017) update, the switch was removed with the claim it is now "automatic". What is real status for new systems with the latest update/systems which had the option on before update is unclear.
  • Use Latency Monitor to check system latency and problems with devices/driver
    Spoiler for the explanation:
    Impact: drivers/hardware can block the system for long time, preventing normal real-time processing.
    Severity: if there is at least one such driver, the system can be unusable for audio.
    Software:, BIOS and optionally: (it can switch SpeedStep, Turbo mode and some other parameters on the fly, it also monitors CPU use and temperature)
     Windows Performance Toolkit from Microsoft (a part of ADK).

    Latency influence.
    The buffer size defines the block lengh in time. F.e. 44.1kHz 64 samples buffer represent 1.45ms audio. In case the system can not process the buffer
    within its maximum time, normaly playback is not possible. Independent from "real time" or any safety buffers.
    Real Time audio adds another limit. Audio processing for a buffer should start as soon as possible after input buffers are ready and ends befor the time when the drivers should start transfering output to the interface. Interface/driver normally have some "safety" extra time. It directly influence complete system latency, but increate the time window allowed for processing.
    Any delays before the processing can begin (relevant DAW thread start runnin on CPU) or interruptions in this processing (preemption of processing thread, CPU lockouts)  plus the processing itself should be within that allowed window.

    Begin with In Depth Latency test on completely idle system and HIGH_LEVEL_IRQL test. That will give you the base of your system latency. Good result should be under 100uSec. With under 1000uSec you still can work, but that means up to 1ms unexpected extra latency. F.e. 32 samples buffer is definitively "no go" and  64 samples also going to be problematic.
    Repeate the test with some load. If the result never jump you are fine, otherwise you need to avoid the activity which trigger these jumps when you work in your DAW.
    Also do DISPATCH_LEVEL test, in idle and under load. In case delays start there, pay more attention to the next Latency Monitor test, may be you can avoid these problem. 

    Start Latency Montioring (different program) and then continue normal system use, f.e. with DAW. That test does not hammer the system as much as In Depth, but that still get some glitches with audio when it is running (especially on slow hardware). That is not a problem by itself.
    The monitor will tell you "no go" with numbers over 1000. Numbers are in microseconds (us, 1/1000000 sec), audio processing "real time" level is in milliseconds (1/1000 sec). As explained before, how much your audio interface/DAW can tolerate depends from the audio hardware, driver and ASIO buffer settings.
    For the reference: 96kHz/32 samples buffer is 0.3ms long, so any numbers over 200 in the monitor can be show stoppers. But 44.1hHz/128 samples buffer is 2.9ms, so under 1000 is normally ok. Note that on one side hardware/drivers/Sonar have "extra" intermediate buffers but on the other side the hardware/drivers have different jitter tolerance level. So with the same buffer settings on the same computer but with different audio interfaces you not only can see different round-trip-time latency, but also different tolerance to delays.
    When something is "bad", the file name will be shown. Google to find which driver course troubles, but note that general windows drivers are shown in some cases and they are rarely the real problem, find underlaying manufacturer driver in that case (f.e. for disk latency MS driver is shown, while the disk firmware/driver is problematic).
    See MSI section later, can help in some cases. If identified driver is common (f.e. ACPI.sys), it works with many system devices. You can try to disable some, but you have no hint which final device is problematic. In case the driver is frameword (f.e. Wdf01000.sys), you can use Windows Performant Toolkit. Run basic profile in Recorded and look at Computation/ DPC/ISR duration by module graph in the Analyser. It can show concrete driver which induct reported delay.

    Highest measured interrupt to process latency can be much higher then ISR/DPC. That means user process (DAW) could not scheduled early, the system could have more "important" (from the system perspective) activity. Note that in general all that adds. So ISR can be delayed by other ISR, then some DPC can prevent user land to run, then system activity can prevent your DAW to run. The last can be improved by changing process/thread priority, but ISR/DPC are woking in the kernel and follow different scheduling rules. 

  • Use REAPER build-in Performance Monitor to check audio/plug-ins timing
    Spoiler for the explanation:
    I know, I know... REAPER is not "welcome" in the Cakewalk world. But it is able to show way more technical information about used plug-ins, real-time performance, ets.
    30 days demo can be installed "portable", and so restless removed later.
    Open View/Performace monitor, right click and select RT and XRun parameters. May be load some plug-ins/audio/MIDI. The monitor will show per track CPU consumption,
    PDC, overal CPU use and most important for the topic the time spend in RT (Real Time) thread (and its limit to avoid troubles). Note that outside factors can greatly influence  RT timing,
    f.e. moving window can increase it in case graphics somehow interfere with audio processing. Also note that unlike REAPER, the whole processing in Cakewalk happens in RT.   
  • Disable unused devices in the device manager
    Spoiler for the explanation:
    Impact: some drivers can interfere with real-time processing, introducing audio drops. Severity: depends from the hardware and drivers.
    Even in case Latency Monitor does not indicate alarm, some drivers can influence how low you can get with ASIO latency. Known cases: NVidia HDMI Audio, several WiFi adapters.
  • Check/change Processor Scheduling
    Spoiler for the explanation:
    Impact: some ASIO drivers work as "background" processes, when foreground processes (Sonar) have priority, that can block the driver. Severity: audio glitches when set wrong, hardware/driver dependent.
    Google for your system, f.e.
    Try both settings under usual work conditions with reduced ASIO buffer setting to find what is right for your system.
  • Exclude audio specific folders and processed from antivirus/antimalware real-time scanning
    Spoiler for the explanation:
    Impact: when new files are written, real-time scanners immediately check them. Severity: can slow down file processing (in some cases drastically), introduce dropouts.
    All such programs have "exceptions" list. Find where these settings can be changed and add at least sonar process (by file name as in Task Manager for your Sonar version) and all folders where you record ("Cakewalk Projects" and such).
    Note that some plug-ins use own temporarily files locations. F.e. Melodyne has internal setting for that and not excluding it from scanning slow down audio parsing up to 10 times for HDD.
  • Exclude at least audio specific folders from Windows indexing
    Spoiler for the explanation:
    Impact: Windows will index all new files by default. Severity: depending from your system, that can interfere with audio recording.
    Note that while you can stop the indexing service or exclude all disks from indexing, that can have small negative side effects.
  • Disconnect from the Internet during critical work
    Spoiler for the explanation:
    Impact: when you are connected to the Internet, Windows periodically starts many "tasks". Severity: can slow down the system, introduce audio glitches, crash, reboot.
    While there are tools and manual operations to prevent that, in reality the user will always "loose the fight". Windows re-enable some services/tasks on updates and/or introduce new.
    There are several tasks which will start even with the Internet disconnected, but at least they are not "killing" the system.
  • Switch graphic card (may be other devices) to MSI mode
    Spoiler for the explanation:
    Originated from:
    In short, try MSI utility v2 to switch devices which introduce high latency in drivers.
  • Try to rise DAW process priority
    Spoiler for the explanation:
    If there is no sufficient cores for all processed which want CPU, OS schedule execution according to priority. The priority can be set in the Windows Task Manager.  More then "above normal" are not recommended since that can delay system processes required by the DAW. There are tools to set it permanently for given executable.
« Last Edit: October 29, 2019, 10:17:51 PM by azslow3 »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
Re: Tips for computer optimization to run Sonar
« Reply #2 on: November 07, 2017, 04:50:35 PM »
Sonar optimization (in Preferences)
Note that I mention only options and settings I think are critical but not "forced" after Sonar installation, unlike f.e. MIDI devices, Control surfaces, VST settings, etc. I mean it is easy to forget (at least for me) to check some set of options while Sonar will "remind" you about other once you start to work with it.
  • Audio
    • Playback and recording
      • Driver mode.
        Spoiler for comment:
        For real-time recording with DAW monitoring, the only reasonable option is ASIO. Search for your specific interface which driver provides it, there is always some way (as the last option, there is ASIO4ALL). If your interface does not support ASIO, but you do not plan to use the setup for recording, you can try other options before (!) ASIO4ALL (since it can trigger problems). You will get too big latency for MIDI keyboard playing, but you still record audio with direct monitoring (may be adding effects like reverb) and for mixing there is no reason to have low latency
      • Share drivers with other programs.
        Spoiler for comment:
        Disable it till you are sure you want it. With many interfaces you can not play youtube while Sonar is blocking the device, but switching can glitch the driver.
      • Use multiprocessing engine.
        Spoiler for comment:
        I do not think there was any recent case when it should not be set, so set it.
      • Plug-in load balancing.
        Spoiler for comment:
        In most cases it should be disabled. By default, it does nothing with the buffer size under 256 (and for real-time recording it is normally lower) and it stress the system more. When mixing projects with several CPU intensive FXes for a single strip, that option can distribute load along several cores. So there are use cases for that settings, but they are not usual.
      • Record Pre-allocate File.
        Spoiler for comment:
        If you have audio glitches during recording on low end system, you can try to set it (f.e. to max recording time). But try my later recommended options first. I have a feeling this option has helped me some time ago, but I am not sure.
      • Fade on Start/Stop
        Spoiler for comment:
        I set it to ~10ms to avoid "clicks" during abrupt audio start/stop
    • Devices.
      Spoiler for comment:
      It make sense to enable only inputs/outputs you really use or plan to use. Changing the list is known to course assignment changes in projects, so enabling all is probably better then enabling less. But enabled connections will appear in the in/out lists, where searching for correct one can be difficult (especially in case names are long).
    • Driver settings.
      • Audio Driver Bit.
        Spoiler for comment:
        Normally you can not change that, but the number here is important. It identify with which precision Sonar can speak with your audio interface. So in which format it receives audio during recording and send for playback. I prefer to match all numbers, so this one, the project bit depth and recording/rendering (see later). Otherwise bit depth conversion is required during which some users observe problems. For not ASIO modes, it make sense to set the option to physically supported by the interface (normally 16bit) since Windows will do bit depth conversion otherwise (which is the worse among possible converters). If you have a choice, record in 24bits. That give a "headroom" for input signal during recording and mixing, even when the target is 16bit. So that make big sense. More then 24bit has almost no sense since the analog source and ADC do not have sufficient precision (unlike digital transfers, the noise level of analog equipment/environment, even top quality, is not zero)
      • 64-bit engine.
        Spoiler for comment:
        There was reports some plug-ins do not like it. Note that while pro people with pro equipment can identify bad 24bit -> 16bit conversion (during several blind tests no single person could be found which can identify the difference between properly mastered and converted/dithered final 16bit material and 24bit equivalent), 64bit vs 32bit is too far away from physically perceptible difference. Still, you can audition the difference between this option set and unset under special conditions, effectively when some processor has logical or mathematical bugs... so it make sense to test the option if you hear something strange in particular project.
      • Stereo panning.
        Spoiler for comment:
        This option is not about interaction with the interface, but many users forget it exists and wonder while a strip volume changes not the way they like after panning.
      • Sampling.
        Spoiler for comment:
        Default for new projects value, set to what you like from the list of physically supported by the interface. Coming from "hi end" marketing idea that 96kHz sounds better is questionable, human is physically unable to hear such hi frequencies, most people can perceive much lower frequency, under 15kHz only, and that can be mathematically correct reproduced by 44kHz sampled signal. Some researches have shown that what "audiophiles" perceive as the "audio improvement" from 96kHz is physically.... artifacts from some part of the equipment triggered by hi frequencies on input which can not be process correctly (the artifacts are in the lower frequency, so audible). Still 96kHz make sense in particular cases, f.e. some system can work with lower latency (128 samples buffer at 96kHz is one half of the time compare with 128 samples buffer at 48kHz and some hardware/drivers lowest limit is not absolute time but the buffer size). Some SoftSynth produce better sound with hi frequency (the reason is used algorithms, note that the sound "quality" is still good after downsampling back), but some of them upsample internally and for other there is Sonar upsampling option. And so that is not an ultimate reason to use 96kHz in projects.

      • Mixing latency.
        Spoiler for comment:
        For ASIO mode only final numbers can be observed. "ASIO panel..." button does not work for many interfaces, use the interface specific launcher. But change settings while this Sonar dialog is opened, there can be glitches otherwise. Sonar audio engine can be explicitly stopped in the Transport module, but I have found pressing the button (with no effect), do modifications (in the interface control) and pressing "apply" works correctly all times, while other methods periodically fail. Also with that sequence you can check that Sonar really see new settings. There is no universal rule what the buffer should be. That is computer, interface, drivers, project and all "tips" in this thread dependent. 256 is a good start for proprietary ASIO drivers. Try lower in case everything works fine only. Note that for "low" and "middle" end interfaces, the lowest allowed settings are almost never work. That are marketing driven numbers, which have probably worked on one system with one specific test software... In many cases I could observe that the driver immediately crash after an attempt to set the lowest number (with Sonar freeze).
    • Sync and Caching
      • File System caching.
        Spoiler for comment:
        So far I could not identify the impact of these options on my work-flows. I normally keep them disabled.
  • MIDI
    • Playback and Recording
      • Record.
        Spoiler for comment:
        Enable all message types which you use. Note that the setting influence Control Surfaces as well and some of them use unusual messages (f.e. PitchBend in MCU, Key Aftertouch in Faderport). So if you have troubles with control surfaces, enable all of them
      • Playback prepare.
        Spoiler for comment:
        Sonar has quite specific MIDI processing. Unlike most (all?) other DAWS, it still use an old concept where recorded MIDI events are processed non in audio buffer quantities (== ASIO buffer size, as used by all VST MIDI processing) but in much bigger quantities (specified in this setting). While logically it make no sense, for some reason (bugs?) old DX plug-ins and periodically Sonar itself "does not like" particular setting. Try 500 or even 1000, but 100, 200 and any  "random" numbers in the range can work better then other in particular case. Note that the number introduce corresponding "delay" when you change MIDI during playback (f.e. tune some MFX parameter). I keep it 50, as long as that works.
  • File
    • Audio Data
      • File bit depth.
        Spoiler for comment:
        I leave Original for import and set Record and Render the same as the project bit depth, which in turn is the audio driver bit depth. So 24/24 or 16/16, depending from the interface I use. The influence on the performance and sound quality is unclear. All the following is pure speculation. But I personally had some audio glitches while recording into 24bit projects but not into 16bit  projects. I have changed several other (mentioned here) options, including this one and everything start to work good. There was a thread about strange sound during recording but not during monitoring with echo. Can that be related? I do not know. I repeat, that advise comes from a rumor and I do not have any technical explanations/comparisons at the moment.
« Last Edit: November 07, 2017, 07:05:20 PM by azslow3 »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
Re: My checklist for Sonar deployment
« Reply #3 on: November 07, 2017, 07:05:29 PM »
Some links to whats look like interesting and other ideas from the Internet. I have not tried most of them:

  • - proposed fixes:
    • Turning off Energy Efficient Ethernet option in network device driver, turning off firewall including its service mpssvc (in registry by changing start to 4, Windows gray out that in service control)
    • hand disabling PowerMizer (I will not try that on notebook...)
  • Since years people attempt to find better option for timer: ;)
    • Enable/disalbe HPET in BIOS and in Windows: bcdedit /set useplatformclock [Yes|No]
    • Disabling Dynamic Ticking with: bcdedit /set disabledynamictick [Yes|no]
    • Timer policy default :bcdedit /set tscsyncpolicy [Enhanced|Default]
  • Show/hide power options in power plan configuration:
« Last Edit: October 29, 2019, 10:05:58 PM by azslow3 »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
Re: My checklist for Sonar deployment
« Reply #4 on: November 07, 2017, 07:05:40 PM »

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1706
Re: My checklist for Sonar deployment
« Reply #5 on: November 07, 2017, 07:05:54 PM »