Burps-and-Farts
Hi n-Trackers:
I download and install the latest builds as Flavio makes them available for download…
I’m at build 2200 now and I see that cpu usage and streaming as being quite stable and consistent over these last series of builds…
However, today while I have this “Test Project” on the timeline and utilizing various tools/and utilities that I normally use, I noticed The streaming of the files I have on this timeline to contain an abnormally high number of glitches in the audio streaming… This is very abnormal for my setup…
I know, that many of you n-Trackers have these issues and post your concerns regularly, regarding this issue, all the time… These tracks were originally recorded to a Hard Drive using the 24-bit @ 48khz. format… I regularly LAN these files between the studio and this P-111 Editing Machine… and between a number of Hard Drives on several machines…
I’m gonna post what I have and the number of plugs and some of the specs. of what is on the n-track timeline, of this test project…
Well, this hasn’t changed for some time as I am not tracking but I want to see how the later builds of n-Track are behaving… for Editing and Repro’ing…
There are 11 stereo tracks on this timeline… All the files are 16-bit at 44.1khz res. I know, that using a sound blaster audio card the files should be 16-bit at 48khz. res… But I experience no alignment issues using this bit/depth rate res. files…
Anyway, the eleven tracks are reduced down to Five Groups… There are five plugins used on this timeline, at the moment… Three plugs are installed on the Master strip to process all the files in the stream… Two plugs are used on two groups that process the tracks that are assigned to the groups… (No plugs on any of the tracks)… So, I use three instances of Anwida Lite verb, one instance each of n-Track multi-band compressor/limiter and Kjheraus classic Limiter…
Today, while doing some volume evolutions on some tracks I discovered some glitches in the audio streaming as the timeline was looping between markers that I have set to loop between…
The DAW is is a P-111 512meg.ram loaded with hard drives and other hardware, and all… The graphics card is an ATI All-in-Wonder 128 Pro… Very minimal, in this day-and-age…
The cpu usage, when I stream this timeline today in build 2200, the CPU Meter is averaging 70 - 83%… Above 80% the CPU meter goes into the “Red”… This is as high as the CPU Meter reads on this test project…
Here’s what I seemed to discover today as the timeline was streaming the files to the audio card…
The audio glitches didn’t seem to have any Bering on how High the CPU Usage meter read… As the selection of the timeline continued to “LOOP” the glitches seemed to be quite random… or… not at the same intervals of time…as the selection Looped…
I went into the prefs. and checked the box that controls “Read all files” even if “Muted”… I have always used that feature… anyway… so as, to consistently use resources… The other box I have always checked is… “Save Backup” (the default is every 10 minutes)… I have that reduced to every 5 minutes… That feature may not be important, to this discovery, but that’s where I have it set…
The monumental discovery I made today is…
Even after the “AUTO SAVE” BOX Flashed to auto-save the n-Track desk I still received the audio glitches… Now that may be unrelated to the audio streaming and the Glitches… But after I went to the “Drop-Down” menu and I “Saved As” the .sng file and re-named the .sng file as … When I re-opened the renamed .sng file There was “NO GLITCHES” in the audio streaming… from that timeline…
Can one of you guys explain what the difference is? and… can you guys that are complaining about the glitches you hear on your DAWs to see if you experience any changes in the audio streaming you hear on your set-ups, when-and-after you DO-A “Save As”?
I would be very interested in hearing if your set-ups behave differently… after diong a 'SAVE AS"… Toward … Audio Glitches…
Bill…
Dear Friend - you may have found something that is very valuable to us in your above post - but see *** below -
before that - when you say the CPU meter turned RED i take it that you that you are using Ns CPU meter - please stixk a piece of thick tape on your screen so you cannot see that meter and use one that shows TOTAL CPU USE not just what N uses -
by using another method of viewing what the WHOLE of your PC is doing you would have discovered that depending on the capabilities of your PC (and yours is very like mine) that 30% in Ns meter is nearly 100% total cpu use and so you get problems -
on our spec PCs - WINDOWS BACKGROUND USE IS (APPROX) 20% when running a program - Ns BACKGROUND USE IS DEPENDANT ON WHAT IS HAS TO DO - USUALLY 40% PLAYING ONE TRACK thats 60% total CPU - add 33% for playing back 11 tracks thats NEAR 93% TOTAL CPU USE - so there is no headroom to cover the times when Windows cuts in to do its housekeeping - THATS WITHOUT COUNTING IN THE RESOURSES THAT PLUGINS USE -
another thing is that if your PC is as cluttered with old tracks that will never be used again, you should back up everything that you are not likely to use for a year onto a CD, delete the original fikes totally from your PC and do a defrag - this is like adding a new drive to your system it will speed it up greatly -
if your tracks are scattered around a drive - the time taken for the head to locate the tracks is far greater than having the tracks all together (as after defrag) -
*** where is the path that SAVE AS used, is it on your C drive or another ?, you may have saved your song on a different drive that is both cleaner or faster -
what drivers/buffer size/ASIO sample rates etc are you using for playback - it these are low then N has to work faster than if they are high - set buffers etc to HIGH -
in prefs set N priority use to HIGHEST - this puts it into realtime use giving N priority all other programs except Windows itself - see* below -
set your PCs performance to BACKGROUND USE - if its set to FOREGROUND use under high loading it will cough and splutter - see below -
* Windows will always make sure that every program/thread running has an amount of CPU time - the higher the priority a program has the more unbroken CPU time it has -
** foreground use is for short bursts of CPU activity - like that which takes place when using a word processor - BACKGROUND use evens the load out and is used for programs that use CPU resourses for a lng time - ie. recording and playing back audio tracks -
Dr J