You go Mark!!! I didn't even spot the IRQ thing. Jan On Sat, 2003-09-13 at 19:10, Mark Knecht wrote: > 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 >
