On Thu, 2003-12-18 at 17:47, Mark Knecht wrote: > 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? You have to play *this* session one time, and after that it's OK. Same thing if I load up another session. Same if I rewind to the beginning of the session from partway through. The first part is fine (reading from disk cache) and the grrtz comes back after that. [snip] > 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. That was my thinking - the read head seeking all over the disk for the various regions. > 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. iostat tells me it's reading < 1Mb/sec. hdparm tells me the disk can do 50Mb/sec. iostat and my ears tell me that whenever there's a dropout, the system is spending about 6% of it's time in iowait. > I suspect the problem is something else.... What are the other options? I've looked at PCI latencies for card and drive controller, IRQ ordering (although APIC seems to make this irrelevant, or at least uncontrollable), OS disk scheduler (anticipatory, deadline and cfq), tagged queueing (high values almost guarantee xruns on recording but don't seem to improve playback). Sheesh, at this rate if I get another dual-processor machine, I'll be able to run jackd at -p 16 -n 2 :-| bye John
