n-track slowww over network
hey,
i used to be able to play n-track files from a network drive (100mbps, xp sp2) but recently things are going less well. when i open a file n-track ‘hesitates’ for like 40 seconds, and then every time when ‘play’ is pressed there’s a very long pause too. During these pauses there’s not a lot of network traffic going on, and the cpu is almost idle too…
adjusting buffers etc doesn’t help. files play well from local disks.
i thought n-track would put all wave files in the RAM (512 mb) or local) swap but apparently it doesn’t, as it transmits the files over the network when it plays…?
any ideas about this?
dee
n-Track doesn’t load wave files into RAM to play them, otherwise you wouldn’t be able to play a very long song! At any given time, it only keeps in RAM the amount that fits in the playback buffers as configured in “Buffering” (plus bufferering to soundcard).
How many tracks in the song? That shouldn’t really matter, though, because the network has enough bandwidth to play literally hundreds of 24b/44.1k stereo files at once.
thanks for your reply…
it used to be just a bit slower to respond over the network (a bit slower than playing everything local) but now the delay is excessive. still nothing really changed about the setup (well i use build 1744 now) with cheap RAM wouldn’t it be nice if the wave files could be loaded into ram? (or swap).
my songs usually have 20+ tracks, but there are often just small chunks of wave files it them. complete songs are somewhere between 50 and 200 MB. with 512 MB ram it should be possible to store a complete song in it…?
There shouldn’t be any reason – when you hit Play it should be able to start quickly rather than load it all into RAM. For playing in loop mode, loading into RAM would be good, though. Currently, we get a glitch on loop restart.
But often I use soundfonts that take up more than half the memory – and my disk drive isn’t fast enough for sfz to run in disk mode (laptop with 5400 RPM drive). But n-Track works fine for songs with a dozen or so active tracks.
Sorry I can’t help figure out what’s not going right on your setup. But something seems wrong; I think it should be able to do it.
yes, it once did it, i’m not sure what changed…
what i meant by loading into ram was: loading the files to ram when opening a song, well for as much as possible anyway. so it plays immediately (from ram) when you hit the play button.
dee
Maybe it’s time to de-frag the drive?
Also, could you mixdown first and play the mixdown over the nework?
drive de-frag and all that stuff has been done… mixing down would help, but of course then you can’t edit the files any more 
dee
By loading the buffers’ worth of data any time you moved the song cursor, it would reduce the amount of time to start playing by whatever your latency is, roughly. For most of us, that’s just a fraction of a second, so clearly there’s more going on when you hit “play” or “record” than pulling data from the disk.
Try running this program on your hard drive and your network drive and comparing the results:
http://www.sesa.es/us/dskbench/dskbench.htm
If there’s an order of magnitude difference, then you have a network problem (i.e., if the network is 10 times slower or worse). If they’re much closer than that, then it’s either an n-Track bug or else n-Track is doing something odd that your network interface software and/or devices don’t like.
If you’re not sure, just post results for both. First, copy the program to the C: folder, and also to your network drive’s foldder. Then go to Start -> Run and type in “cmd” (omit the quotes), which brings up a DOS window. Then do the following:
C:
dskbench
N:
dskbench
I can’t count the number of times my computer has “suddenly” stopped doing something. Then a week later I discover a change I made - and of course that was what the problem was… How could I have been so blind?
Perhaps it is an N-Track bug, but it’s worth thinking about every change you’ve made to both your server and client PC. For example, power saving. If you’ve allowed the drive to spin down to save power, it will take a few seconds to spin up again. Firewall? Anti-virus? The list goes on. 
well i just have to live with it i guess… the network is o.k., drives throughput o.k., n-track o.k. when files are played locally…, pc optimized with known tweaks…
i’ll just have to pack the files and unpack them on the other computer…
dee.
It kinda sounds to me like Windows is just initally accessing the shares slowly. When you first browse the “server” using Windows Explorer/My Network Places, etc., are you seeing the same long pause before any shared folders show up?
I don’t know what the exact fix for this would be, just looking for the root cause. I’m currently seeing this (i.e. initially slow network share browsing) on my own PCs at home, but I haven’t taken time (yet) to look into it. All I know is share browsing was fast a few months ago, but now I get a long pause on the initial access(es).
If I find anything potentially useful, I’ll post it here, of course.
Tony
i don’t have any problems with accessing other files (directly) via the network…
a thing i did change a while ago was converting from fat to ntfs (both machines, win xp). maybe i should use bigger clusters… i can’t imagine that would have a big impact… (also because it still works very well locally)
dee
Aha. Potentially a very good clue.
I don’t know the specific protocols involved, but I am a network protocol expert, and things like data chunk size can have a very dramatic effect on performance over a network, even if it doesn’t matter locally. In many cases, this would show up with generic disk IO performance testing, but in some cases it can be application specific.
If you ran DskBench, post your results. It might give us a clue. (Post results for local and network drives.)
Meanwhile, try going to Preferences -> Buffering and increasing the buffer size for disk buffers. (Are you using the default of high buffering, or have you modified the configuration?)
BTW: I often see folks say that if you’re using ASIO, the buffering settings don’t matter. This is only partially correct. The disk buffering settings are pertinent regardless, and disk buffering is a factor for network drive performance.