Re: [linux-audio-user] Tracking down overruns

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Tracking down overruns
From: Benji Flaming (lau_AT_solobanjo.com)
Date: Sun Sep 14 2003 - 04:47:15 EEST


> 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...

I'm glad to meet you. I've been playing with Pro Tools since 4.3.1, and my
studio is running currently running MIX plus on an old beige G3/300 running
MacOS 9. I've often wanted to migrate over to Windows, but we'd lose all of
our plug-ins. Pro Tools is actually one of my biggest motives for moving to
Linux - one gets tired of jumping through flaming hoops every time
DigiDesign or Apple release new hardware or software.

> 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.

Well...I *do* have a third drive hooked up to the Promise controller, but
upon installing it, I discovered that my power supply doesn't want to supply
power to another drive - even though I have enough power hookups. I can
only use the drive if I disconnect power from my LS120, CD-ROM or Windows
hard drive. Time to buy a new power supply....

> 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.)

I'm running Blackbox - we seem to be cousins.

For what it's worth, I've also posted my XF86Config:
http://www.comevisit.com/NorthernSunrise/latency/XF86Config
It has a few things I need to fix, but nothing that I think would affect
audio performance.

> 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

My machine is absolutely adamant that the sound card *has* to go there :( I
spent many frustrating and fruitless hours trying to address this issue. I
sifted through every single BIOS setting, juggled the cards all over the
place, but the only way I could get the card off IRQ 5 was by disabling that
IRQ. When I did this, it moved the card up to IRQ 4, and so on. In short,
my machine *always* gives the sound card the lowest-priority IRQ, and
provides no way (that I could find) to assign IRQs manually. Ultimately, I
put things back as they were, and decided to be more careful next time I buy
a board.

I *might* be able to force it to share an IRQ with something else. Would
this be worth tampering with?

> (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...

Since I wasn't ready to use it, I don't think I built drivers for it when I
built the kernel. Might this explain the discrepancy?

Also, I've done quite a bit of scouring around for information on disk cache
settings. Mostly, what I find are messages asking how to set a maximum disk
cache size, followed by silence, or by replies saying not to bother with it.
Often the discussion quickly descends into a debate about the soundness of
Linux's VM system, with the original question about the disk cache system
being ignored. I did find a patch by Rik van Riel
(http://surriel.com/patches/2.4/2.4.20-rmap15c) which appears to provide
sysctl parameters for cache size restraints, but I'd have to download and
build a 2.4.20 kernel, downgrade my module utilities, etc.

Even if something else is causing my overruns now, I certainly suspect that
real-time performance could be enhanced by a bit of cache settings tweaking.
If anyone has any info on doing this with a 2.6.test5 kernel, I would love
to get it. My curiosity has been awakened :)

Thanks again for the continued help!

|)
|)enji

Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Sep 14 2003 - 05:04:46 EEST