[linux-audio-user] Tracking down overruns

[Jan Depner]

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
>