I'm mixing my first project in T where I'm now using automation curves for pans and fades and doubling some tracks etc.
I haven't had many audio glitch problems that freezing or rendering tracks couldn't solve - until now.
My latest edit, I can't even work with anymore since on playback with the tracks unmuted that I want, I get rapid clicks on any automation curve transitions, or even when I move the mouse. If I solo a track, then the clicks go away, but I want to mix track in context with the others.
My system is setup as the following:
AMD Athlon 1.2 GHz
256 MB RAM
Win98SE
Latest version of T
KX drivers on SBLive sound card
Would adding more system RAM help me out with this issue?
-Scott
Willadding more system memory fix this in T?
-
- KVRAF
- 4908 posts since 10 Aug, 2004 from Colorado Springs
-
- KVRAF
- 4644 posts since 28 Nov, 2002 from Chicago
unlikely. Too little system RAM will dramtically throttle performance of a PC, but with 98SE, unless you have a lot of plugins open or large sound fonts etc in memory then adding another 256MB will probably not bring the benefits you are looking for. CPU speed and hard drive access speeds are as likely to be problems here, and even low powered video cards can cause problems.
It sounds to me simply like you have an edit too large for your machine.
Is your CPU going into red often, or is the little '!' symbol showing on the CPU meter to suggest disk access underruns?
Consider dropping the ASIO buffer size to free up some CPU - you don't need low latency when mixing.
Make sure your drive is defragmented.
Consider rendering out some of your tracks as audio files. You can use the render and add option to keep the source material, and if you don't render in level/pan/eq/effect processes that you are still adjusting then you are free to add these treatments to the rendered audio.
At a push use Tracktion's freeze function to temporarily fix a few tracks whilst you work on mixing others.
It sounds to me simply like you have an edit too large for your machine.
Is your CPU going into red often, or is the little '!' symbol showing on the CPU meter to suggest disk access underruns?
Consider dropping the ASIO buffer size to free up some CPU - you don't need low latency when mixing.
Make sure your drive is defragmented.
Consider rendering out some of your tracks as audio files. You can use the render and add option to keep the source material, and if you don't render in level/pan/eq/effect processes that you are still adjusting then you are free to add these treatments to the rendered audio.
At a push use Tracktion's freeze function to temporarily fix a few tracks whilst you work on mixing others.
Someone shot the food. Remember: don't shoot food!
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
My CPU meter is hanging out at about 40-50% - that was the first thing I checked. My project folder is full of stuff, will that matter? I'm not using a great deal of it.valley wrote:
Is your CPU going into red often, or is the little '!' symbol showing on the CPU meter to suggest disk access underruns?
...
Consider dropping the ASIO buffer size to free up At a push use Tracktion's freeze function to temporarily fix a few tracks whilst you work on mixing others.
Also, freezing tracks is already part of my standard practice but this was happening even then.
I'll see about defragmentation - I ran a full defrag about a month ago, maybe it's time to do it again.
-Scott
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Agreed with the above-- be warned, though... I do this when working on a huge mix, and you need to have a plan of attack before diving into it.
My suggestion:
Render to a single audio file, and then mute the rendered tracks, and shrink them down to free up screen real-estate to boot. But do NOT start adding effects and panning to this audio file, because you'll get to a point of no return... sure, you may get the results you want -for this particular mix-, but when you decide to shake things up again, pretty much the whole sound that you've sculpted will be lost because you'll be going back to the original (now muted) tracks and switching stuff around.
When you see something that needs tweaking, unmute the tracks, tweak, and then take the time to re-render to a new single audio file. Once you know you won't go back to the old one, delete it to free up drive space.
At the end of the day, I think that freezing is a more elegant solution, since it does what the above describes automatically. Unfreezing a single track to 'work on it' takes an extra step in rendering, though... because it'll re-render the remaining frozen tracks into a single audio file. Whereas with the straight-up 'render' option, you don't have to re-render until after you've tweaked a little.
Defragmenting will not help, and in fact may hinder performance when playing back audio. Defrag is helpful for system drives because you are loading programs into memory, and therefore they will load into memory more quickly if they're defragmented. However, disk streaming already has the drive head skipping all over the platter (streaming multiple audio files), so defragmenting won't give you a performance boost.
It also doesn't matter how cluttered your project directory is. Even if you have 2000 unused audio files in there, it's still only accessing the ones in your edit, so the others are nothing more than 'ghosts' floating around, neither harming nor helping your edit's performance.
Greg
My suggestion:
Render to a single audio file, and then mute the rendered tracks, and shrink them down to free up screen real-estate to boot. But do NOT start adding effects and panning to this audio file, because you'll get to a point of no return... sure, you may get the results you want -for this particular mix-, but when you decide to shake things up again, pretty much the whole sound that you've sculpted will be lost because you'll be going back to the original (now muted) tracks and switching stuff around.
When you see something that needs tweaking, unmute the tracks, tweak, and then take the time to re-render to a new single audio file. Once you know you won't go back to the old one, delete it to free up drive space.
At the end of the day, I think that freezing is a more elegant solution, since it does what the above describes automatically. Unfreezing a single track to 'work on it' takes an extra step in rendering, though... because it'll re-render the remaining frozen tracks into a single audio file. Whereas with the straight-up 'render' option, you don't have to re-render until after you've tweaked a little.
Defragmenting will not help, and in fact may hinder performance when playing back audio. Defrag is helpful for system drives because you are loading programs into memory, and therefore they will load into memory more quickly if they're defragmented. However, disk streaming already has the drive head skipping all over the platter (streaming multiple audio files), so defragmenting won't give you a performance boost.
It also doesn't matter how cluttered your project directory is. Even if you have 2000 unused audio files in there, it's still only accessing the ones in your edit, so the others are nothing more than 'ghosts' floating around, neither harming nor helping your edit's performance.
Greg
-
- KVRAF
- 3441 posts since 15 Mar, 2003
Yes. Rendering the tracks you are not working on is just a temporary fix that you will be deleating.
As an example, I have a song with a complex drum track that uses about ten drums on seperate tracks.
If I try to play those drums and the rest of the instruments together on my old and slow computer it just refuses to play.
So, I rendered all of the non-drum tracks so that I can play them as I work on the drums while hearing them in context with the other instruments.
When I get the drums about right I render the drums and then work on and mix the other instruments.
I keep deleting the temporary renders and re-rendering as needed to do further work.
In the end I should have a good total mix with the effects and EQ all set properly in midi.
Then I can render the entire tune and do final tweaking and mastering on the final audio track.
Hopefully I will get a faster machine soon, and then I can find new ways to over-load that!
As an example, I have a song with a complex drum track that uses about ten drums on seperate tracks.
If I try to play those drums and the rest of the instruments together on my old and slow computer it just refuses to play.
So, I rendered all of the non-drum tracks so that I can play them as I work on the drums while hearing them in context with the other instruments.
When I get the drums about right I render the drums and then work on and mix the other instruments.
I keep deleting the temporary renders and re-rendering as needed to do further work.
In the end I should have a good total mix with the effects and EQ all set properly in midi.
Then I can render the entire tune and do final tweaking and mastering on the final audio track.
Hopefully I will get a faster machine soon, and then I can find new ways to over-load that!
-
- KVRAF
- 4644 posts since 28 Nov, 2002 from Chicago
Defragging *can* help. Whilst what you say is correct, you are not factoring in the effect of read ahead caching, which can help in audio playback. Read ahead caching is typically defeated when the data to be read is fragmented.Lunch Money wrote: Defragmenting will not help, and in fact may hinder performance when playing back audio.
Audio recording always benefits from a nice clean defragmented area to write to.
AIUI though FAT32 benefits far more from a defrag regime than does NTFS.
Someone shot the food. Remember: don't shoot food!
-
- KVRAF
- 6490 posts since 14 Jun, 2004 from Rochester, NY
Dude, do what I did and get a new mobo/cpu/mem-- go to www.newegg.com and get some nice stuff for about $330 you can improve all cpu probs 
ROnC
ROnC
-
- KVRAF
- 5851 posts since 9 Jul, 2002 from Helsinki
Where I can dowload this Will-a-ding Memory Fixer?
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
OK,
I defragged and froze just about every one of my 15 tracks in this edit.
Still got the crackling.
Now, I noticed that it happens only when my mouse is over one of the 'resize' lines, either to resize the track height, or width or on the pan/volume filter or any automation curve, where the arrow pointer turns into something else.
I've still got to check to see if this is happening on a clean edit. It didn't at first - it would have driven me nuts.
I'm going to check tonight.
Regarding buying a new MOBO/processor/memory - yeah, I've thought of that - one of the $400 HP full systems would do me just fine, but I don't have $400 or $330 right now. I can spring $40 for some addl. memory if it might help. I thought it might, but nobody who has replied yet seems to think so.
-Scott
I defragged and froze just about every one of my 15 tracks in this edit.
Still got the crackling.
Now, I noticed that it happens only when my mouse is over one of the 'resize' lines, either to resize the track height, or width or on the pan/volume filter or any automation curve, where the arrow pointer turns into something else.
I've still got to check to see if this is happening on a clean edit. It didn't at first - it would have driven me nuts.
I'm going to check tonight.
Regarding buying a new MOBO/processor/memory - yeah, I've thought of that - one of the $400 HP full systems would do me just fine, but I don't have $400 or $330 right now. I can spring $40 for some addl. memory if it might help. I thought it might, but nobody who has replied yet seems to think so.
-Scott
-
- KVRAF
- 4644 posts since 28 Nov, 2002 from Chicago
Well that shouldn't be the result of an underpowered machine. A 1.2 Athlon is more than capable of playing back a few tracks of frozen audio.rockstar_not wrote:OK,
I defragged and froze just about every one of my 15 tracks in this edit.
Still got the crackling.
Something else is broken in your setup I'd guess. Possible candidates would be videocard performance/driver/intterupt problems. Hard drive running in non-DMA mode. Background services occassionally grabbing the processor for longish periods of time.
Check you have no IRQ conflicts (especially with the soundcard). Check the tasks running in the background and disable applications that load at boot time.
Check your hard drive is running in DMA mode, and also just check it isn't running in some safe (read crippled) state.
Take a look in the registry to see what is getting loaded when windows first starts.
Someone shot the food. Remember: don't shoot food!
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
I agree with the above assessment-- if rendering your tracks didn't solve the problem, then it's definitely something else other than memory or normal performance issues. As mentioned, IRQ conflicts (esp. with vid card) are prime suspects.
Greg
Greg
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
OK,
I checked my hard drive settings - its UDMA, but no read ahead optimization (I think I set it this way from the old TASCAM article on optimizing Win98 for audio) - should I have some read-ahead optimization setup?
Also, I have it set so Windows manages the swap file. Should I change this to a fixed amount and if so, what should I consider when setting the size? I've got 256 MB system RAM. I've seen recommendations all over the map.
No IRQ conflicts - at least no little warnings or exclamation points in the Device Manager in the System/Settings.
Thanks so far for everyone's help.
-Scott
I checked my hard drive settings - its UDMA, but no read ahead optimization (I think I set it this way from the old TASCAM article on optimizing Win98 for audio) - should I have some read-ahead optimization setup?
Also, I have it set so Windows manages the swap file. Should I change this to a fixed amount and if so, what should I consider when setting the size? I've got 256 MB system RAM. I've seen recommendations all over the map.
No IRQ conflicts - at least no little warnings or exclamation points in the Device Manager in the System/Settings.
Thanks so far for everyone's help.
-Scott
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
As long as your hardware supports it, go for the read-ahead optimization.
Set a fixed swap file-- the more memory you have, the less of a swap file you need, despite MS's recommendation. However, with 'only' 256 RAM, I'd pretty much follow their spec and go with a 512 MB swap file. That's just me, though.
Still not 100% convinced your problems will vanish, as it sounds like a video card, or 2 devices sharing resources... but we'll see!
Greg
Set a fixed swap file-- the more memory you have, the less of a swap file you need, despite MS's recommendation. However, with 'only' 256 RAM, I'd pretty much follow their spec and go with a 512 MB swap file. That's just me, though.
Still not 100% convinced your problems will vanish, as it sounds like a video card, or 2 devices sharing resources... but we'll see!
Greg
-
- KVRian
- 779 posts since 3 Apr, 2003 from UK
I'll suggest something that has worked for me - adjusting PCI latency (different to soundcard latency - anyone who has read PC Notes in the last issue of Sound On Sound will know where I'm going)
Go to http://www.mark-knutson.com/t3/ for the details.
To summarise, though - PCI latency is how long a card can grab the bus, and all the while a card has the bus, nothing else can get to it, and this includes AGP graphics cards. It seems that many video card drivers set their latency to the maximum of 255, which indeed my Radeon 9200 was set to. So if the graphics card has hold of the bus when the sound card is required it can lead to clicks and drop outs etc. Having reduced my video card latency to 64 and increased soundcard latency to 80, I haven't had a single crackle since.
The program for doing this from this website is called Double Dawg but unfortunately it doesn't run under 98 (2000 or XP only).
However http://www.geocities.com/phileosophos/t ... tency.html on the same subject refers to a program PowerStrip from http://entechtaiwan.net/util/ps.shtm which should let you tweak at least your graphics card settings under 98.
No guarantees though!
Go to http://www.mark-knutson.com/t3/ for the details.
To summarise, though - PCI latency is how long a card can grab the bus, and all the while a card has the bus, nothing else can get to it, and this includes AGP graphics cards. It seems that many video card drivers set their latency to the maximum of 255, which indeed my Radeon 9200 was set to. So if the graphics card has hold of the bus when the sound card is required it can lead to clicks and drop outs etc. Having reduced my video card latency to 64 and increased soundcard latency to 80, I haven't had a single crackle since.
The program for doing this from this website is called Double Dawg but unfortunately it doesn't run under 98 (2000 or XP only).
However http://www.geocities.com/phileosophos/t ... tency.html on the same subject refers to a program PowerStrip from http://entechtaiwan.net/util/ps.shtm which should let you tweak at least your graphics card settings under 98.
No guarantees though!