Subject: Re: [linux-audio-user] Tracking down overruns
From: Mark Knecht (markknecht_AT_comcast.net)
Date: Sun Sep 14 2003 - 03:10:32 EEST
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
This archive was generated by hypermail 2b28 : Sun Sep 14 2003 - 03:25:09 EEST