13 Sep
2003
13 Sep
'03
6:29 p.m.
Greetings all! I am attempting to initiate a long unattended 2-channel
audio recording - perhaps lasting for an hour or two - but I am prevented
from doing so by periodic overruns which occur at regular intervals. This
interval changes according to my system configuration. Currently, I
consistently get an overrun about 20 minutes after I start recording.
My system is an AMD Athlon XP 1700+ with 256mb DDR266 memory. Video card is
an ATI Radeon 7500/64mb. Sound card is an M-Audio Audiophile 2496. I'm
running Slackware 9.0. My kernel version is 2.6.test5. Prior to this
kernel I was using 2.4.21 with low-latency and preemptible kernel patches -
with exactly the same overrun issue. I'm using jackd version 0.79.2,
Ardour/GTK 0.378.0, and libardour 0.686.0 (all built from CVS source a few
weeks ago.) I'm starting jackd with the command:
jackd -v -a -R -d alsa -d ice1712 -r 44100 -p 2048
I don't want to clog everyone's mailbox with an even bigger message, so I've
posted a bit of additional info online.
Results from running latancytest0.42-png:
http://www.comevisit.com/NorthernSunrise/latency/3x256.html
http://www.comevisit.com/NorthernSunrise/latency/test2/3x256.html
My .config file from my most recent 2.6.test5 kernel build:
http://www.comevisit.com/NorthernSunrise/latency/.config
My jack, and ardour version numbers, and hdparm info for hda and hdb:
http://www.comevisit.com/NorthernSunrise/latency/configuration
I can see from the latency tests that *something* is causing spikes,
particularly during disk write, but I'm not sure how to determine precisely
what it is. Is there any way to obtain a snapshot of processor usage at the
exact moment of an overrun? Any help or advice (or reminders about what
info I've neglected to give) would be very much appreciated!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
13 Sep
13 Sep
7:02 p.m.
If you're not already doing it, use reiserfs or xfs. From your pictures
it looks like you might be using ext3. There are a few processes that
should be dead before you start doing realtime. I use a script with the
following:
killall -9 autorun 2>/dev/null
killall -9 artsd 2>/dev/null
killall -9 jackd 2>/dev/null
rm -rf /tmp/jack*
killall -9 /usr/lib/ardour/ardourx 2>/dev/null
killall -9 oafd 2>/dev/null
killall -9 xbiff 2>/dev/null
killall -9 envy24control 2>/dev/null
killall -9 /usr/bin/aplay 2>/dev/null
I'm using almost the same hardware setup as you and I hardly ever get
overruns (1700+ and ST Audio DSP2000 C-Port). One thing that did give
me problems was using IO_support set to 3. The sync seemed to give me
problems. I set both of mine to 1 (no sync). I also kicked up to 512
MB of memory from 256 and that helped some too. You can see what I've
done to my system at
http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html
Jan
On Sat, 2003-09-13 at 15:16, Benji Flaming wrote:
Greetings all! I am attempting to initiate a long
unattended 2-channel
audio recording - perhaps lasting for an hour or two - but I am prevented
from doing so by periodic overruns which occur at regular intervals. This
interval changes according to my system configuration. Currently, I
consistently get an overrun about 20 minutes after I start recording.
My system is an AMD Athlon XP 1700+ with 256mb DDR266 memory. Video card is
an ATI Radeon 7500/64mb. Sound card is an M-Audio Audiophile 2496. I'm
running Slackware 9.0. My kernel version is 2.6.test5. Prior to this
kernel I was using 2.4.21 with low-latency and preemptible kernel patches -
with exactly the same overrun issue. I'm using jackd version 0.79.2,
Ardour/GTK 0.378.0, and libardour 0.686.0 (all built from CVS source a few
weeks ago.) I'm starting jackd with the command:
jackd -v -a -R -d alsa -d ice1712 -r 44100 -p 2048
I don't want to clog everyone's mailbox with an even bigger message, so I've
posted a bit of additional info online.
Results from running latancytest0.42-png:
http://www.comevisit.com/NorthernSunrise/latency/3x256.html
http://www.comevisit.com/NorthernSunrise/latency/test2/3x256.html
My .config file from my most recent 2.6.test5 kernel build:
http://www.comevisit.com/NorthernSunrise/latency/.config
My jack, and ardour version numbers, and hdparm info for hda and hdb:
http://www.comevisit.com/NorthernSunrise/latency/configuration
I can see from the latency tests that *something* is causing spikes,
particularly during disk write, but I'm not sure how to determine precisely
what it is. Is there any way to obtain a snapshot of processor usage at the
exact moment of an overrun? Any help or advice (or reminders about what
info I've neglected to give) would be very much appreciated!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
7:37 p.m.
If you're not already doing it, use reiserfs or
xfs. From your pictures
it looks like you might be using ext3. There are a few processes that
should be dead before you start doing realtime. I use a script with the
following:
Nope - I'm using reiserfs. However, I do know for a fact that I was running
envy24control when I got the overruns. I'll make sure it's dead next time.
One thing that did give
me problems was using IO_support set to 3. The sync seemed to give me
problems. I set both of mine to 1 (no sync).
I'll look into this - thanks again!
You can see what I've
done to my system at
http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html
Actually, I went through this entire document a few weeks ago. I already
owe you a tremendous debt of gratitude for putting it together. It was
exactly what I needed in order to get started with serious Linux audio.
I'll take another look, though, in case I neglected something.
Thanks again!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
11:23 p.m.
Benji,
I'm just killing envy24control to make sure it's dead before I crank up
another iteration of it. I normally have it running all the time. It
could be the IO_support thing. That gave me the same type of problems.
Jan
On Sat, 2003-09-13 at 16:24, Benji Flaming wrote:
If you're
not already doing it, use reiserfs or xfs. From your pictures
it looks like you might be using ext3. There are a few processes that
should be dead before you start doing realtime. I use a script with the
following:
Nope - I'm using reiserfs. However, I do know for a fact that I was running
envy24control when I got the overruns. I'll make sure it's dead next time.
One thing that did give
me problems was using IO_support set to 3. The sync seemed to give me
problems. I set both of mine to 1 (no sync).
I'll look into this - thanks again!
You can see what I've
done to my system at
http://myweb.cableone.net/eviltwin69/ALSA_JACK_ARDOUR.html
Actually, I went through this entire document a few weeks ago. I already
owe you a tremendous debt of gratitude for putting it together. It was
exactly what I needed in order to get started with serious Linux audio.
I'll take another look, though, in case I neglected something.
Thanks again!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
14 Sep
14 Sep
6:29 a.m.
On Sat, Sep 13, 2003 at 03:09:26PM -0500, Jan Depner wrote:
killall -9 autorun 2>/dev/null
killall -9 artsd 2>/dev/null
killall -9 jackd 2>/dev/null [and so forth ...]
This sequence can be simplified and made a little more safe.
a) use "--quiet" instead of "2>/dev/null", so that any failure to
run
killall is not hidden, yet it won't complain if there are no
processes with that name,
b) use "--signal KILL" instead of "-9", to ease later understanding,
c) use "--wait" as well, so that potential timing issues are excluded
(if you did the sequence of killall's at higher priority than the
processes you have killed, then it is theoretically possible for you
to start new processes before the processes you killed have actually
died, and these new processes may therefore not run as expected ...
the technical term is "race condition".)
d) test for and use just the default SIGTERM signal, as there are some
programs that need to undo some of the work they have done, and a
SIGKILL (the -9) allows them no chance to do so. (An example are
programs that create permanent shared memory segments or other IPC
arcania; and then only delete them properly if not SIGKILLed.)
A rule of thumb is to prove to yourself that SIGTERM doesn't work
before adopting SIGKILL.
e) place the commands in a file in /usr/local/bin or $HOME/bin, include
that directory in your PATH, make sure the file is executable
"chmod +x killit", and add a "set -v", so that when you run it you
can
immediately see it's progress. If you've never written a file
containing commands to execute, have a go, you'll love the idea.
#!/bin/sh
set -v
killall --quiet --wait --signal KILL autorun
killall --quiet --wait --signal KILL artsd
killall --quiet --wait --signal KILL jackd
rm -rf /tmp/jack*
killall --quiet --wait --signal KILL /usr/lib/ardour/ardourx
killall --quiet --wait --signal KILL oafd
killall --quiet --wait --signal KILL xbiff
killall --quiet --wait --signal KILL envy24control
killall --quiet --wait --signal KILL /usr/bin/aplay
f) and to really go all the way, do some "factoring" to make it easier
to add new programs ... although this is no use if programs need
different signals:
#!/bin/sh
set -x
for PROCESS in autorun artsd jackd /usr/lib/ardour/ardourx oafd \
xbiff envy24control /usr/bin/aplay; do
killall --quiet --wait --signal KILL $PROCESS
done
rm -rf /tmp/jack*
References:
man 7 signal
man 1 killall
man 1 bash
tested on Debian GNU/Linux and Red Hat 9
--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/
11:09 a.m.
Really nice! I'm an old UNIX guy so I just used the brute force
method. I did forget to add that I kill syslogd and crond before I run
Ardour.
Jan
On Sun, 2003-09-14 at 03:13, James Cameron wrote:
On Sat, Sep 13, 2003 at 03:09:26PM -0500, Jan Depner
wrote:
killall -9 autorun 2>/dev/null
killall -9 artsd 2>/dev/null
killall -9 jackd 2>/dev/null [and so forth ...]
This sequence can be simplified and made a little more safe.
a) use "--quiet" instead of "2>/dev/null", so that any failure to
run
killall is not hidden, yet it won't complain if there are no
processes with that name,
b) use "--signal KILL" instead of "-9", to ease later understanding,
c) use "--wait" as well, so that potential timing issues are excluded
(if you did the sequence of killall's at higher priority than the
processes you have killed, then it is theoretically possible for you
to start new processes before the processes you killed have actually
died, and these new processes may therefore not run as expected ...
the technical term is "race condition".)
d) test for and use just the default SIGTERM signal, as there are some
programs that need to undo some of the work they have done, and a
SIGKILL (the -9) allows them no chance to do so. (An example are
programs that create permanent shared memory segments or other IPC
arcania; and then only delete them properly if not SIGKILLed.)
A rule of thumb is to prove to yourself that SIGTERM doesn't work
before adopting SIGKILL.
e) place the commands in a file in /usr/local/bin or $HOME/bin, include
that directory in your PATH, make sure the file is executable
"chmod +x killit", and add a "set -v", so that when you run it you
can
immediately see it's progress. If you've never written a file
containing commands to execute, have a go, you'll love the idea.
#!/bin/sh
set -v
killall --quiet --wait --signal KILL autorun
killall --quiet --wait --signal KILL artsd
killall --quiet --wait --signal KILL jackd
rm -rf /tmp/jack*
killall --quiet --wait --signal KILL /usr/lib/ardour/ardourx
killall --quiet --wait --signal KILL oafd
killall --quiet --wait --signal KILL xbiff
killall --quiet --wait --signal KILL envy24control
killall --quiet --wait --signal KILL /usr/bin/aplay
f) and to really go all the way, do some "factoring" to make it easier
to add new programs ... although this is no use if programs need
different signals:
#!/bin/sh
set -x
for PROCESS in autorun artsd jackd /usr/lib/ardour/ardourx oafd \
xbiff envy24control /usr/bin/aplay; do
killall --quiet --wait --signal KILL $PROCESS
done
rm -rf /tmp/jack*
References:
man 7 signal
man 1 killall
man 1 bash
tested on Debian GNU/Linux and Red Hat 9
--
James Cameron mailto:quozl@us.netrek.org http://quozl.netrek.org/ 
12:11 p.m.
Hi,
Sunday 14 September 2003 14:30 skrev Jan Depner:
Really nice! I'm an old UNIX guy so I just used
the brute force
method. I did forget to add that I kill syslogd and crond before I run
Ardour.
<rant>
I sincerely hope though that the day will come when all these temporary
changes aren't necessary.
It bugs me that I can't keep _one_ configuration for all computer related
work.
I want a system where I can start all services/daemons I use and still have
reliable (preferably good) performance with audio applications.
--
It's been quite a while since I wandered into Windows-land. Earlier these
issues where similar there too... is it still so?
What about OS X, my gut feeling is that you don't need to worry as much with
it, or is it similarily broken?
...Not that I would -ever- consider switching (got a long list of related and
unrelated reasons for that), but it's good to know if one's wishes will ever
be granted or if they are just pipe-dreams.
</rant>
/Robert
12:29 p.m.
On Sun, Sep 14, 2003 at 03:53:30 +0200, Robert Jonsson wrote:
Hi,
Sunday 14 September 2003 14:30 skrev Jan Depner:
FWIW I dont do any of those things. I even found that MySQL and apache had
been running of my RT audio system for a week or so withouyt problems. I
do generally kill magicdev though.
- Steve
Really nice! I'm an old UNIX guy so I just
used the brute force
method. I did forget to add that I kill syslogd and crond before I run
Ardour.
<rant>
I sincerely hope though that the day will come when all these temporary
changes aren't necessary.
It bugs me that I can't keep _one_ configuration for all computer related
work.
I want a system where I can start all services/daemons I use and still have
reliable (preferably good) performance with audio applications. 
13 Sep
13 Sep
8:29 p.m.
On Sat, 2003-09-13 at 13:16, Benji Flaming wrote:
Greetings all! I am attempting to initiate a long
unattended 2-channel
audio recording - perhaps lasting for an hour or two - but I am prevented
from doing so by periodic overruns which occur at regular intervals. This
interval changes according to my system configuration. Currently, I
consistently get an overrun about 20 minutes after I start recording.
Pretty interesting. Does it really seem to come after 20 minutes from
when recording started? Or is one maybe happening every 20 minutes?
I do not remember anyone bringing anything like this up before.
The 5 second interval on the disk copy stress test would be the journal
file getting written, I think. The location of the journal file is at a
different place on the disk than the sequential data you're writing, so
the disk head has to seek for that location, causing a bit of delay.
It's not particularly bad.
The one time 4mS spike is anybodies guess at this point. Maybe you want
to look very carefully at every process that's running to see if any of
them would use your audio drive. While you showed hda and hdb, normally
that would be two drives on the same IDE cable. If this is how you are
set up, and presuming that hda is the system and hdb is a second hard
drive for audio, then I would consider putting the second hard drive on
a separate IDE cable. If you are recording to your system drive, then
this spike could be kernel related, or anything else that's mysterious.
;-)
Any help or advice (or reminders about what
info I've neglected to give) would be very much appreciated!
lspci
cat /proc/interrupts
Just more general info on the hardware you are using.
BTW - MY opinion is that unless you are doing recording and playback
together, you should not bother recording with such a low latency
setting. There is no advantage in getting the audio to disk in 3mS vs.
10mS when you are just recording. Even though my system can do 1.2mS And
seems to work, I never use it. Back off on the buffer size and let the
system breath a bit.
Good luck,
Mark
9:07 p.m.
[Note - I accidentally sent a copy of this message from another e-mail
address. I'm sending this copy since I don't expect the first to show up.
Sorry for the double-post if I am mistaken in my expectation.]
On Sat, 13 Sep 2003 15:14:18 -0700, Mark Knecht wrote:
Pretty interesting. Does it really seem to come after
20 minutes from
when recording started? Or is one maybe happening every 20 minutes?
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.
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.
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.
The one time 4mS spike is anybodies guess at this
point. Maybe you want
to look very carefully at every process that's running to see if any of
them would use your audio drive. While you showed hda and hdb, normally
that would be two drives on the same IDE cable. If this is how you are
set up, and presuming that hda is the system and hdb is a second hard
drive for audio, then I would consider putting the second hard drive on
a separate IDE cable. If you are recording to your system drive, then
this spike could be kernel related, or anything else that's mysterious.
hda is Linux, hdb is Windows. I shouldn't have even bothered with specs for
hdb. Sorry for complicating the diagnostic process.
lspci
http://www.comevisit.com/NorthernSunrise/latency/lspci
(I told it to be verbose)
cat /proc/interrupts
http://www.comevisit.com/NorthernSunrise/latency/interrupts
Motherboard is an Iwill XP333:
http://www.iwillusa.com/products/ProductDetail.asp?vID=8&CID=93
BTW - MY opinion is that unless you are doing
recording and playback
together, you should not bother recording with such a low latency
setting. There is no advantage in getting the audio to disk in 3mS vs.
10mS when you are just recording. Even though my system can do 1.2mS And
seems to work, I never use it. Back off on the buffer size and let the
system breath a bit.
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.
:)
Thanks again for the help!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
10:25 p.m.
On Sat, 2003-09-13 at 15:53, Benji Flaming wrote:
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 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) 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
11:26 p.m.
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:
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 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) 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
14 Sep
14 Sep
midnight
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."
3 a.m.
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 :)
I ought to be in bed right now, but I did manage to find what I was looking
for. The values I want to adjust are in /proc/sys/vm/. Some basic
observations about the effects of different cache settings on I/O
performance can be found at:
http://drscriptt.riverviewtech.net/linux/enotes/bdflush.html
I also found a page with some other potentially useful information for
tracking down hard disk I/O operations (although the goal of the document is
quite unrelated to audio streaming):
http://www-2.cs.cmu.edu/~mukesh/hacks/spindown/t1.html
Lastly, I changed the IO_support setting to 1, and Ardour has now been
happily recording for an hour and a half! I was also able to run the
latency test without overruns (the 4 ms. spike dropped to 2.7 ms.). Thanks
so much for your help, Mark & Jan!
I'll be looking into the disk caching parameters, and if I come up with any
promising results, I'll certainly post my findings.
Best regards,
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
7:33 a.m.
Hi,
http://www-2.cs.cmu.edu/~mukesh/hacks/spindown/t1.html
Lastly, I changed the IO_support setting to 1, and Ardour has now been
happily recording for an hour and a half! I was also able to run the
latency test without overruns (the 4 ms. spike dropped to 2.7 ms.). Thanks
so much for your help, Mark & Jan!
This thread became a really good lowlatency tutorial, great! :) I'm not sure
what this IO_support thing is, but I guess it's in Jan's guide.
There's just one other thing I thought I'd add that I didn't see mentioned
anywhere.
By default a linux system is running cron daemons that schedule the execution
of different "things" at recurring intervals.
Though I've never heard of anything happening with 20 minute intervals. That
the spike occured 20 minutes into the the recording also speaks against it.
It may be a good idea to turn them of though.
/Robert
8:13 a.m.
On Sun, Sep 14, 2003 at 11:21:33 +0200, Robert Jonsson wrote:
Hi,
Turn it on with hdparm -c 1 /dev/hd<whatever>
It turns on 32bit access for IDE drives, sounds important, it was off
on my system.
- Steve
http://www-2.cs.cmu.edu/~mukesh/hacks/spindown/t1.html
Lastly, I changed the IO_support setting to 1, and Ardour has now been
happily recording for an hour and a half! I was also able to run the
latency test without overruns (the 4 ms. spike dropped to 2.7 ms.). Thanks
so much for your help, Mark & Jan!
This thread became a really good lowlatency tutorial, great! :) I'm not sure
what this IO_support thing is, but I guess it's in Jan's guide. 
5:39 a.m.
"Benji Flaming" <lau(a)solobanjo.com> wrote:
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.
http://www.sweetwater.com/store/manufacturer.php?m=Digidesign
I spent some time earlier this evening looking at some of their cards.
Figure at some time in your process you're going to have to deal with
it anyway. {Their cables cost as much as my sound card.}
I'm harboring this secret hope that Avid's going to port the SGI version
of DV Xpress to linux {and that as a result linux's rep as a multimedia
platform will improve by leaps and bounds.} someday soon.
I'm running Blackbox - we seem to be cousins.
Maybe a dedicated video/audio editing workstation with a Blender/Combustion
style interface done in SDL? It would be a great way to harness all of those
command line audio programs.
7:10 p.m.
On Sat, 2003-09-13 at 18:47, Benji Flaming wrote:
Yep, this is a problem. My solution was to use a 1394 drive for my audio
drive, both under Pro Tools (Win XP) and Linux. It then doubles as a
simple way to get data between boxes if I don't want to spend time
messign with getting Samba working...
Possibly. Not sure. I don't remember building drivers for mine, but
that's another PC than this one.
I see that there have been many other response to this thread, so I'll
have to read what other said.
Cheers,
Mark
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.
PTLE for me. Thought about an 002 and decided before I jumped I'd give
Linux a try.
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.
Absolutely. I need to go to Guitar Center an buy my latest 6.01 upgrade
if I want to stay on the treadmill.
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....
I'm running Blackbox - we seem to be cousins.
Once again yes...
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.
I'm terrible at kernel configuration, so I hope someone else will help
more with this part.
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.
OK, I certainly get how this has happened, but I eventually tricked my
Dell P3 500 box that runs GigaStudio into playing nice. It was no fun
though. Here's the short version of the story...
1) There are two ways IRQs get assigned, both depending on BIOS:
a) BIOS gives you an option to set an IRQ on a per PCI slot basis
b) BIOS jest sets them.
2) My P3-500 (which sounds like your machine) just assigned specific
IRQs to specific slots. In this case I had to look at what cards were
getting what IRQs and then rearrange cards to get the IRQ.
3) In your case I see the eth0 has IRQ11 which is a good IRQ. I looked
at the IWill page but was unclear if the Ethernet controller is on the
motherboard or a PCI card. If it's a PCI card, then the way I handled my
Dell was to remove EVERY card except the VGA adapter and then put one
card in at a time, see what interrupt BIOS gave it, decide what card I
wanted to have that interrupt, put that card in and move on to the next
card. It meant a number of boot cycles, but now the machine has run for
18 months with a AudioPhile 2496 and an RME HAmmerfall Light and a 1394
adapter and an Ethernet controller and it's worked great.
I think it took most of a day to get that to work, but I've probably had
close to 500 days of trouble free operation since then.
I *might* be able to force it to share an IRQ with something else. Would
this be worth tampering with?
It is, as long as you're comfortable with the process and realize that
all this screwing around can, if you are unlucky, break something
physically. It's not likely to happen, but it is a small risk.
The thing you probably want to understand is that right now every
Ethernet packet that arrives has higher priority than your sound card or
your disk drives. IRQ11 beats IRQ14/15 for the disks or IRQ5 for the
sound card.
So, if your Ethernet adapter is a card, take it and the sound card out,
put the sound card in the Ethernet slot, and then reboot and see what
you get.
(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?
15 Sep
15 Sep
1:15 a.m.
PTLE for me. Thought about an 002 and decided before I
jumped I'd give
Linux a try.
Are you running an 001, then? I bought my Digidesign AudioMedia III card
(2-in, 2-out, analog or digital) just a few months before the 001 was
announced. Needless to say, it was rather frustrating that there was no
upgrade path. My studio partner and I were also unfortunate enough to
purchase our MIX plus system just shortly before Pro Tools HD was announced.
Absolutely. I need to go to Guitar Center an buy my
latest 6.01 upgrade
if I want to stay on the treadmill.
We're still at 5.1.3. We'd have to upgrade all of our plug-ins to MacOS X
versions if we switched to PT6 :(
Yep, this is a problem. My solution was to use a 1394
drive for my audio
drive, both under Pro Tools (Win XP) and Linux. It then doubles as a
simple way to get data between boxes if I don't want to spend time
messign with getting Samba working...
This sounds like a great solution. In a pinch, it would also be away of
getting files between here and the studio. I'll definitely have to look
into that.
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.
I'm terrible at kernel configuration, so I hope someone else will help
more with this part. OK, I certainly get how this has happened, but I
eventually tricked my
Dell P3 500 box that runs GigaStudio into playing nice. It was no fun
though. Here's the short version of the story...
Thanks, I'll try your technique as soon as I can make the time.
The thing you probably want to understand is that
right now every
Ethernet packet that arrives has higher priority than your sound card or
your disk drives. IRQ11 beats IRQ14/15 for the disks or IRQ5 for the
sound card.
Yup - this irks me to no end, but I wasn't able to fix it in my initial
effort.
So, if your Ethernet adapter is a card, take it and
the sound card out,
put the sound card in the Ethernet slot, and then reboot and see what
you get.
This was the first thing I tried. Same IRQ asignments even after the
change. I'd look up the BIOS settings so I could better explain the
problem, but my Linux box is building a new kernel right now.
Possibly. Not sure. I don't remember building
drivers for mine, but
that's another PC than this one.
Come to think of it, I'm not sure whether I've even looked for the drive
under Linux since I plugged it in. It might actually be there. I suppose
I'd have to build the controller drivers in order to access the drive at any
reasonable speed, however.
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
6:48 a.m.
Just wanted to post one final update before I go to bed (which I should have
done hours ago.) I spent quite a while playing with disk buffer settings,
looking through the kernel source, and digging up info online. Needless to
say, I learned a *lot* along the way. I made some tweaks, including
changing the values of 4 numeric constants in the kernel source, and
altering the values of /proc/sys/vm/dirty_*
The changes I made *did* seem to improve performance (at least on the
benchmarks), but I was still getting big spikes on the disk write graph,
caused (as Mark pointed out) by the journal being written to a different
part of the disk. It took me several hours to remember that my disused
Debian partition was formatted as ext2. Upon remembering this, I ran the
test on this partition, and achieved maximum latencies of 1.5-1.6 ms. for
all 5 tests. Here are the results of running latencytest-0.42-png on both
filesystems, with and without the disk buffer modifications:
reiserfs, without tweaks:
http://www.comevisit.com/NorthernSunrise/latency/regularreiserfs/3x256.html
reiserfs, with tweaks:
http://www.comevisit.com/NorthernSunrise/latency/tweakedreiserfs/3x256.html
ext2, without tweaks:
http://www.comevisit.com/NorthernSunrise/latency/regularext2/3x256.html
ext2, with tweaks:
http://www.comevisit.com/NorthernSunrise/latency/tweakedext2/3x256.html
The biggest bottleneck is certainly the journal, but the disk buffers appear
to be contributing a little bit as well. The changes that I made were
fairly extreme, not to mention uneducated. I suspect that these changes
would also have a strong detrimental effect on overall data throughput,
since I essentially crippled the entire caching system. I'd be interested
in seeing whether continued experimentation could lead to the same 1.6
millisecond results with milder settings. Just for the record, the changes
I made were:
- Changed MAX_WRITEBACK_PAGES in mm/page-writeback.c from 1024 to 8
- Changed ratelimit_pages in mm/page-writeback.c from 32 to 2
- Changed MIN_PDFLUSH_THREADS in mm/pdflush.c from 2 to 16
- Changed MAX_PDFLUSH_THREADS in mm/pdflush.c from 8 to 32
- Changed /proc/sys/vm/dirty_background_ratio from 10 to 1
- Changed /proc/sys/vm/dirty_expire_centisecs from 3000 to 1
- Changed /proc/sys/vm/dirty_ratio from 40 to 1
- Changed /proc/sys/vm/dirty_writeback_centisecs from 500 to 1
The basic idea was to force frequent buffer flushes, make each flush
smaller, and spread the flushes throughout different threads to stagger the
timing.
I'm off to get some sleep now. Thanks to everyone for the help!
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
8 a.m.
Interesting results. I'm not sure I'm willing to give up my journal
though...
Another variable you might try (if you havent allready) is the disk
elevator - its pretty common on systems with intelligent disks to turn it
way down.
- Steve
14 Sep
14 Sep
8:02 a.m.
Have you made sure you jack tmp directory is mounted from a tmpfs
filesystem? I was getting presistent overruns until Fernando setup Planet
to do it automatically.
- Steve
15 Sep
15 Sep
1:14 a.m.
Have you made sure you jack tmp directory is mounted
from a tmpfs
filesystem? I was getting presistent overruns until Fernando setup Planet
to do it automatically.
Yep - I did this early in the process. Thanks for the tip, though.
|)
|)enji
Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."
7788
days inactive
7790
days old
linux-audio-user@lists.linuxaudio.org
22 comments
7 participants
participants (7)
-
Benji Flaming -
James Cameron -
Jan Depner -
Mark Knecht -
Rick Taylor -
Robert Jonsson -
Steve Harris