On Sat, 2003-09-13 at 15:53, Benji Flaming wrote: > I haven't double-checked with my current configuration (I will do so and > confirm) but I did test this with an earlier configuration, and waiting an > arbitrary length of time before initiating recording didn't affect the > length of time before the overrun. Interesting situation. Should be interesting to see what you find out. > > I'm beginning to wonder whether this is related to disk-caching. My theory > would be: > > 1. System begins recording with an empty cache > 2. Cache fills with audio data > 3. System flushes cache, attempting to write too much data at once > 4. Overrun caused > 5. Recording stops > 6. Back to 1 > > This would explain the consistent timing of the overrun, and would > potentially explain the 4 ms spike showing up at exactly the same spot in > both latency tests. Very possibly. > > I'm certainly a newcomer to Linux audio configuration, but I do know that > Pro Tools users under MacOS 9 were told to reduce disk cache size. I can't > remember what the recommended size was - somewhere between 256k and 512k > IIRC - but problems would appear if the cache was either too big or too > small. I'll be googling for info on Linux disk cache settings as soon as I > send this message. Welcome! I'm a Pro Tools user under Windows. On the Windows side we have not had these warnings about reducing disk cache, as far as I can remember... > > hda is Linux, hdb is Windows. I shouldn't have even bothered with specs for > hdb. Sorry for complicating the diagnostic process. Forgiven. No problem. However, this means you are doing latency testing to your system drive. Is this correct? You do not have a second, separate audio drive at this point? I ask as I notice you have the Promise ATA controller on IRQ11. Also, maybe I forgot, but what windowing environment are you running? KDE? Gnome? I run fluxbox and think it's quite nice for audio, if you like minimalistic environments. I raise this question as I had a lot fo similar problems with KDE, and never tried Gnome after I got fluxbox working well. (And it's very easy to try out without effecting what ever your other environment is.) > > > > lspci > > http://www.comevisit.com/NorthernSunrise/latency/lspci > (I told it to be verbose) OK, one potential problem I spot is the IRQ for your audio controller is about the worst it could have at IRQ5. As a Mac guy you are forgiven if you don't realize how screwed up Intel architecture interrupts are. The non-APIC IRQ priority order goes: 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7 so at 5 your audio card is 'behind' nearly everything else in the system. Normally you want to try and get it on IRQ 9, 10 or 11. Actually, since you have the Promise on IRQ11, you'd be in fat city with an audio drive attached to it and the sound card on IRQ9 or 10, or at least that's been my experience. (Strange that the Promise is there in lspci but doesn't show up in /proc/interrupts. Maybe some more knowledgeable Linux person could help me understand why. I don't know... > I certainly could for this particular application. Realtime audio > processing is essential to some of the other things I'll be working on, > however, and for this reason I'm trying to get the problems ironed out now. > :) Hey, go for it if you can get it to work. By the time you get down to this level of operation these machines are a bit of art and black magic. I work on chips that go into PCs fpr a living, so I'm cool with it, but it drives me nuts sometimes, so don't think you're alone! ;-) > > Thanks again for the help! My pleasure, for what it's worth. - Mark
