Look under Audio Devices -> Advanced to find “keep devices open”. It’s been there since V3.0, I’m pretty sure.
| Quote (I Am Spartacus @ April 06 2006,09:41) |
| My soundcard is NVIDIA nForce Audio. In input and output devices, I have always used Wav Mapper for recording because it has always worked well. The other ones cause static and skips. |
Aha.
First, that's a gaming-oriented card with lots of fancy audio processing options. Try turning them all off in the nVidia control panel.
Even then, it may internally buffer things, causing additional latency that's unaccounted for by n-Track.
Second, consider updating your drivers. The best bet is probably the "unified driver", which has support for ASIO and WDM. http://www.nvidia.com/object/nforce_udp_winxp_2.00.html
Third, go to n-Track "Preferences -> Audio Devices -> Advanced" and make sure that "WDM" and "ASIO" types are enabled (as well as MME, which is probably what you're using). There's also Direct Sound, which I don't think is useful.
OK that panel going back to "Audio Devices". First, try the ASIO driver. If that doesn't work, try the WDM driver. For the nVidia, not the mapper.
Finally, disk issues can cause dropouts but won't cause sync problems between tracks. Synchronization all happens way before info gets posted to the disk. Then the disk either keeps up or not (and if not, you get problems, but not sync problems). It certainly won't hurt you to defrag the disk.
My N-force on-board audio just stopped working one day and I have been unable to get it working. It did not seem to be a hardware problem but the system just stopped recognizing it for some reason. I tried refreshing the drivers, uninstalling etc. My solution was a new soundcard. This was not on my DAW so it wasn’t critical. If it had been there would have been even more justification to get something better.
In general Nvidia is a reliable company but I am not sure they are as committed to their audio stuff as their video. I actually suspect that something in one of the driver updates messed things up and I didn’t figure out where to roll it back to. Who knows? The new soundcard ended up saving enough time and hassle to be worth the money.
Jim
| Quote (learjeff @ April 06 2006,10:42) |
| Look under Audio Devices -> Advanced to find "keep devices open". It's been there since V3.0, I'm pretty sure. |
I've got version 2.
| Quote (clevermind @ April 06 2006,09:47) |
| is your computer set to give higher priority to background tasks ? |
Nah, it's set so that NTrack has highest priority.
I had A Computer about 2 years ago running ASIO on A 1Gig Athlon that started to slow down when recording or playback.I did everything trying to correct the problem and finally ending changing to A new board and CPU.I later found that I had 1 bank of Ram bad.The old Computer would check the ram on startup and read the ram was good.I found the bad Ram when installing the new board it would not startup.I pulled 1 bank of Ram out the new board and by accident that was the bad bank and the board started up.I don’t know if that is your problem but you might check it. 
I had been working on a song and thought that I was having trouble staying on beat. Turns out part of the problem is poor synchronization between tracks. To check, I fed a click track back through the recording input – and it was really a mess. The rerecorded click track lags significantly. I tried turning off the ‘keep devices open’ check box, but every time I look back, n-track has turned it back on. Anybody have any idea why n-track won’t let me turn it off? There are are three places where you can tell n-track not to use the system timer, two in the advanced audio settings, and one in the midi settings. I turned all three off. Didn’t help. I am running n-track build 2088 and my audio interface is an M-audio audiophile usb, using the M-audio ASIO driver.
| Quote (I Am Spartacus @ April 06 2006,22:11) | ||
Nah, it’s set so that NTrack has highest priority. |
giving higher priority to background tasks is a recommended setting for daws
| Quote (tspringer @ April 06 2006,23:43) |
| I had been working on a song and thought that I was having trouble staying on beat. Turns out part of the problem is poor synchronization between tracks. To check, I fed a click track back through the recording input -- and it was really a mess. The rerecorded click track lags significantly. I tried turning off the 'keep devices open' check box, but every time I look back, n-track has turned it back on. Anybody have any idea why n-track won't let me turn it off? There are are three places where you can tell n-track not to use the system timer, two in the advanced audio settings, and one in the midi settings. I turned all three off. Didn't help. I am running n-track build 2088 and my audio interface is an M-audio audiophile usb, using the M-audio ASIO driver. |
maybe usb controller irq is shared with another device
try also to plug your soundcard to another usb port
if several devices are plugged on the same usb controller, available bandwidth is divided equally between them.
<!–QuoteBegin>
| Quote |
| maybe usb controller irq is shared with another device try also to plug your soundcard to another usb port if several devices are plugged on the same usb controller, available bandwidth is divided equally between them. |
Well, that’s interesting. No matter what settings I’m using I’m not able to get rid of the lag with my SB Live External. I think this USB issue could be worth looking into.
There was also a tip further up about kX drivers. I’ll check it out. Thanks.
Anyway, the lag I’m experiencing is not so bad that recording is impossible. So, gonna give it a try during the easter holidays for a little recording session. Fingers crossed!
I switched from the M-Audio ASIO driver to the WMD driver. When I did this I got drop outs, crackling and snapping. This suggested a problem with buffer settings, which I had reduced some while back to try to reduce latency. Setting buffers back to the defaults cleared up the drop outs and, lo, the synchronization of the tracks became acceptable.
I get the impression that the ASIO driver is based on a “bend but don’t break” philosophy for handling buffer overruns and underruns wheras the WMD driver follows a “break but don’t bend” philosophy. The ASIO driver will allow synchrony to be broken and keep right on going – and I suspect, if the over/under runs are not too severe it will resynchronize as quickly as possible. If over/under runs are too numerous, asynchrony just gets worse and worse as recording proceeds. With WMD driver you either hear dropouts and pops or you get an error message. This is one time the “break don’t bend” philosophy might be better. I was really getting frustrated with myself (thinking that I was unable to follow a beat) before I figured out what was going on.
I missed a clue when I fed the output from my click-track back into the input. The tracks were nearly synchronous at the beginning and got further and further apart as recording went on.
By the way, thanks to clevermind for your suggestions. I tried them, but as you can see from my previous posting, the problem had primarily to do with handling of buffers.
Tim
tspringer, when you did the click track loopback test, did you have both “Use system timer for” boxes UNchecked? It sounds to me like you had one checked and the other not.
Unless you used different soundcards for playback and recording, or used different timer sources for playback and recording, it’s hard to figure how the time difference would increase. Definitely something wrong there.
Jeff
| Quote (learjeff @ April 06 2006,11:23) | ||
Aha. First, that's a gaming-oriented card with lots of fancy audio processing options. Try turning them all off in the nVidia control panel. Even then, it may internally buffer things, causing additional latency that's unaccounted for by n-Track. Second, consider updating your drivers. The best bet is probably the "unified driver", which has support for ASIO and WDM. http://www.nvidia.com/object/nforce_udp_winxp_2.00.html Third, go to n-Track "Preferences -> Audio Devices -> Advanced" and make sure that "WDM" and "ASIO" types are enabled (as well as MME, which is probably what you're using). There's also Direct Sound, which I don't think is useful. OK that panel going back to "Audio Devices". First, try the ASIO driver. If that doesn't work, try the WDM driver. For the nVidia, not the mapper. Finally, disk issues can cause dropouts but won't cause sync problems between tracks. Synchronization all happens way before info gets posted to the disk. Then the disk either keeps up or not (and if not, you get problems, but not sync problems). It certainly won't hurt you to defrag the disk. |
I'm not sure where the Nvidia control panel is. Can you help me locate it?
Also, I don't have that "Advanced" button. I think that only started appearing with later versions.
I should point out that I don't have a current version of NTrack because I tried installing it once and it messed up my system so much that I had to do a system restore.
<!–QuoteBegin>
| Quote |
| April 07 2006,13:28 tspringer, when you did the click track loopback test, did you have both “Use system timer for” boxes UNchecked? It sounds to me like you had one checked and the other not. |
Learjeff
I unchecked both ‘use system timer’ boxes on the audio devices panel and also unchecked the ‘use system timer’ in the panel that is on the midi devices panel. Well I guess there is always the chance that what I meant to do is not what I did…After it didn’t seem to help I rechecked them all (I try to change only change one thing at a time when degugging). Anyway, with all three ‘use system timer’ boxes checked and buffering increased, the WMD driver is doing fine with synchronizaton. Tonight I’ll go back to the ASIO driver and see if it the synchronization problems re-appear. Thanks for the thought. Hopefully I will learn something from this.
Tim
<!–QuoteBegin>
| Quote |
| Tonight I’ll go back to the ASIO driver and see if it the synchronization problems re-appear. |
Well I tried…
For some reason, the ASIO drivers no longer show up in the driver list, even though the ‘show ASIO drivers’ box is checked. I think that I’ll just lick my wounds, sit back, and see if ntrack is completely stable running with the WMD drivers. But I really hate it when seemingly random things happen. Very little of what happens can possibly be random…there is just a reason that I can’t see.
Spartacus, the “Advanced” button has been there since V3.0. Are you using V2.xx?
Properties -> Audio Devices
then look in the lower left hand corner.
tspringer, yeah, that’s a bitch. It’s hard to diagnose when things jump around a lot.
Most folks get the best results with the boxes unchecked, but that doesn’t work with some gaming and built-in soundcards – it should with any soundcards intended for audio recording. And it’s a function of MOBO chipset too, I suspect.
Just make sure you’re running at 48kHz if you’re using a Soundblaster or Audigy. There are other cards where that’s important too, though I don’t know specifically which ones.
I have worked n-track really hard for the last two days using th WMD drivers. It has probably run for something like 18 hours without a crash even with n-track drums and crystal synth running in two instrument channels and 8 - 10 audio tracks. BUT I have found that new tracks will not synchronize if n-track starts having trouble with buffer over-runs. As the project grew, I first froze most tracks and increased buffer size to the max, and that fixed the synchronization until I added another track or two. I started having trouble again and then I noticed that CPU utilization was still fairly low (bouncing between 30 and 50 percent). This made me think that the disk drive itself was the bottleneck, so I defragemented my hard drive to increase drive efficiency. This gave me enough increase in transfer speed to finish out the project. Bottom line points: If you are having synchronization problems, try increasing buffer size to see if it fixes the problem. Also, having a really fast hard drive is just as critical as having a really fast CPU/motherboard.
tspringer – Aha – you’re getting dropouts. That’s the real problem, not really sync problems per se. The dropouts (caused by buffer overruns in this case) often cause sync problems. What I see is that the track with dropouts ends up coming in early after the dropouts, as though there was a deletion from the wave file.
Can you tell (from whatever message tells you you’re getting buffer overruns) whether it’s recording buffers or disk buffers that are overrun? If it’s disk buffers, then something isn’t right with your disk subsystem. You don’t need a “really fast hard drive”, you need a “barely adequate” one (in terms of most computers these days). Many older laptop systems have problems in this area.
Are you working in 24/96 or 24/192? If you’re running 24/44, the data rate for 10 mono audio tracks is only about 1.3MB/sec, which is a small fraction of the throughput even for 4500 RPM laptop drives (typical throughput of 10MB/sec). Of course, there’s more to it than throughput since it’s 10 different files, and so seek time matters. But playing 10 mono tracks while recording one should be like falling off a log (unless you’re using a higher sample rate).
Try running dskbench and post your output, so we can see if there’s an issue there, or if there’s a better optimal buffer size for disk buffers. Note that this program assumes tracks are 16/44.
learjeff Posted on April 10 2006,10:16
<!–QuoteBegin>
| Quote |
|
Aha – you’re getting dropouts. That’s the real problem, not really sync problems per se. |
learjeff - Thanks a bunch for taking the time to reply.
I’m sure that dropouts have been the source of most of my “apparent sync problems”. What is odd is that I frequently haven’t heard the dropouts in the track. If I had been hearing pops, clicks, or gaps, I would have immediately done something to eliminate dropouts. But because I wasn’t hearing anything like that, it took a while to catch on. Maybe the buffer overruns are during the initial disk access (e.g. because some kind of access lag), right at the start of the recorded track, which is often silent, so the dropout is hard to hear. I don’t see anything in my harddisk’s benchmarks to suggest that this might be happening though. Perhaps you will see something…
I am running 24/44.
The disk benchmarks for my machine are:
DskBench 2.12
© 1998, SESA, J.M.Catena (cat@sesa.es, www.sesa.es)
Timer Check = 1000 (should be near 1000)
CPU Check = 50.09 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 6.058648
Open = 0 ms
Write = 9891 ms, 25.88 MB/s, CPU = 1.16 %
Flush = 235 ms
Rewin = 0 ms
Read = 10813 ms, 23.68 MB/s, CPU = 0.83 %
Close = 0 ms
BlockSize = 131072, MB/s = 6.20, Tracks = 73.67, CPU = 0.35 %
BlockSize = 65536, MB/s = 6.27, Tracks = 74.57, CPU = 0.49 %
BlockSize = 32768, MB/s = 5.33, Tracks = 63.32, CPU = 0.88 %
BlockSize = 16384, MB/s = 5.48, Tracks = 65.10, CPU = 1.49 %
BlockSize = 8192, MB/s = 6.23, Tracks = 74.12, CPU = 3.19 %
BlockSize = 4096, MB/s = 7.48, Tracks = 88.94, CPU = 7.39 %