> > On Thu, 2003-12-18 at 14:25, eviltwin69@xxxxxxxxxxxx wrote: > > John, > > > > First, is your data disk separate from your system disk? If not, > > this could be part of your problem. > > The data is on a separate partition, not a separate disk. It may be part > of the problem, but it seems to me not a big part because the pattern of > disk reads and dropouts only happens when I'm playing a session for the > first time. The disk activity pattern is completely different when the > machine is otherwise idling. And unless I go for a raid setup, the > system would still have to read all the audio data off one disk. John, Is it that you must play *this* session one time, or can you play *any* session one time and then the next session is OK? It would be an interesting test to run Ardour with some dummy session, experience the problem, run the dummy session again, experience it's fixed, and then load the session you are using now and see what happens on the first pass with that session. It may be audio caching that's fixing things, or possibly it's some part of Ardour that's not getting loaded until it's needed. I saw a couple of problems similar to this with Pro Tools before I added my first 1394 audio drive a few years ago. Never understood why it happened. > > > Second, what FS are you using? > > Reiserfs > > > Ext2 is better than ext3 but still not as good as Reiserfs. Another > > thing, turn off syslogd, crond, etc before recording. > > Recording (one or two tracks at a time, anyway) is OK. It's reading more > than about 3 tracks that seems to cause the trouble. And if the output > from top is anything to go by, it happens because disk reads cause the > cpu to spend too much time waiting on io to prevent the audio buffers > from emptying. I went through a patch a few weeks ago where I killed > off every process that wasn't necessary, and the problem persisted. > I think this is where there are some misconceptions that we all have about measuring disk performance WRT audio apps. Logically, if you are reading back many audio tracks from a drive, and if they all happen to be located very closely together, then there will be less seek time required to get the data. However, if they are all scattered over the drive then you could spend a huge amount of time seeking to actually get very little data from the drive. A quick calculation: 44.1K samples/second * 24-bits/sample = 132.3K Bytes/Sec for a mono channel. At only 8 channels you'd barely be over 1MB/Sec in streaming bandwidth. (2MB/Sec if they are stereo.) Certainly your disk can handle that if the system cooperates. I suspect the problem is something else.... (At least with FAT32 I can determine where the file is on the drive and move it if required. How do I do this with ext3 or reiserfs?) Good luck, Mark
