9 Sep
2004
9 Sep
'04
2:10 a.m.
Lee Revell wrote:
On Wed, 2004-09-08 at 17:38, Lee Revell wrote:
Well, actually there is an R9 out today ...
I have it patched, compiled and installed.
audiobox:~# uname -r
2.6.9-rc1-bk12-vp-r9
(had to lowercase the extraversion stuff to comply with debian policy
when making .deb with make-kpkg)
I've set all the /proc and /sys stuff I could find in the wiki (console
output below). Still, I get xruns reported by my ecasound 8 analogueOsc
thingy. Interestingly, though, they now only happen when I start the
second ecasound process to record from the jack outputs of the first.
I'll double check that with previous kernel versions when I get a
chance, but I'm fairly sure this is new and an improvement.
Subjectively, the sound of the analogueOscs is smoother and the zipper
noise from controller movements seems much less, but still the first
ecasound reports xruns when it exits.
As I said earlier today, I'm not complaining. I'm just trying to help
out by reporting. I'm eager and willing to help with debugging. Is there
anything I may have missed?
What other info should I provide?
Thanks,
Eric Rz.
audiobox:~# cat /proc/sys/kernel/*_preemption
1
1
1
1
audiobox:~# grep . /proc/irq/*/*/threaded
/proc/irq/1/i8042/threaded:1
/proc/irq/11/YMFPCI/threaded:1
/proc/irq/12/i8042/threaded:1
/proc/irq/14/ide0/threaded:1
/proc/irq/15/ide1/threaded:1
/proc/irq/4/eth0/threaded:1
/proc/irq/8/rtc/threaded:1
/proc/irq/9/ICE1712/threaded:1
audiobox:~# echo 0 > /proc/irq/9/ICE1712/threaded
audiobox:~# echo 0 > /proc/irq/8/rtc/threaded
audiobox:~# echo 0 > /proc/irq/11/YMFPCI/threaded
audiobox:~# grep . /proc/irq/*/*/threaded
/proc/irq/1/i8042/threaded:1
/proc/irq/11/YMFPCI/threaded:0
/proc/irq/12/i8042/threaded:1
/proc/irq/14/ide0/threaded:1
/proc/irq/15/ide1/threaded:1
/proc/irq/4/eth0/threaded:1
/proc/irq/8/rtc/threaded:0
/proc/irq/9/ICE1712/threaded:0
audiobox:~# grep . /sys/block/*/queue/max_sectors_kb
/sys/block/hda/queue/max_sectors_kb:1024
/sys/block/hdc/queue/max_sectors_kb:1024
audiobox:~# echo 16 > /sys/block/hda/queue/max_sectors_kb
audiobox:~# echo 16 > /sys/block/hdc/queue/max_sectors_kb
audiobox:~# grep . /sys/block/*/queue/max_sectors_kb
/sys/block/hda/queue/max_sectors_kb:16
/sys/block/hdc/queue/max_sectors_kb:16
If you want to try the new 2.6 low latency kernel,
here is a QuickStart:
Start with:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
Then apply these patches in this order:
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc1.bz2
http://redhat.com/~mingo/voluntary-preempt/patch-2.6.9-rc1-bk12.bz2
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk12…
This will give you the irq threading settings in /proc that other posters referred to.
Please keep in mind that this is not completely stable yet, I would not
recommend it for production use, but it works very well for many
people. You are likely to have better results on a regular 32 bit
single processor (that means no hyperthreading) x86 desktop system,
because this has been well tested.
Ugh, typo, the last patch should be 'R6'
and not 'R9'. 
9 Sep
9 Sep
2:36 a.m.
On Wed, 2004-09-08 at 23:53, Eric Dantan Rzewnicki wrote:
Lee Revell wrote:
Yeah, I know, but R9 had a bug that caused it to not compile for me; R6
was the last version that worked. Maybe you are just not hitting that
bug...
On Wed, 2004-09-08 at 17:38, Lee Revell wrote:
Well, actually there is an R9 out today ...
If you want to try the new 2.6 low latency kernel,
here is a QuickStart:
Start with:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
Then apply these patches in this order:
http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc1.bz2
http://redhat.com/~mingo/voluntary-preempt/patch-2.6.9-rc1-bk12.bz2
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc1-bk12…
This will give you the irq threading settings in /proc that other posters referred to.
Please keep in mind that this is not completely stable yet, I would not
recommend it for production use, but it works very well for many
people. You are likely to have better results on a regular 32 bit
single processor (that means no hyperthreading) x86 desktop system,
because this has been well tested.
Ugh, typo, the last patch should be 'R6'
and not 'R9'. I have it patched, compiled and installed.
audiobox:~# uname -r
2.6.9-rc1-bk12-vp-r9
(had to lowercase the extraversion stuff to comply with debian policy
when making .deb with make-kpkg)
OK, great! I have been meaning to make .debs of these but have not had
time.
I've set all the /proc and /sys stuff I could find
in the wiki (console
output below). Still, I get xruns reported by my ecasound 8 analogueOsc
thingy. Interestingly, though, they now only happen when I start the
second ecasound process to record from the jack outputs of the first.
I'll double check that with previous kernel versions when I get a
chance, but I'm fairly sure this is new and an improvement.
Subjectively, the sound of the analogueOscs is smoother and the zipper
noise from controller movements seems much less, but still the first
ecasound reports xruns when it exits.
As I said earlier today, I'm not complaining. I'm just trying to help
out by reporting. I'm eager and willing to help with debugging. Is there
anything I may have missed?
What other info should I provide?
All your settings look good. I think you are in good shape. xruns are
normal when connecting and disconnecting a jack client, this does not
seem to hurt anything, and they should not happen once you are rolling.
If you do get any xruns, here is how to debug them. Reset the
preemption latency counter like this:
echo 0 > /proc/sys/kernel/preempt_max_latency
Then start jackd. When you see an xrun, copy the contents of
/proc/latency_trace to a file, then post them here.
Also, are you running debian unstable? What output do you get when you
run 'getconf GNU_LIBPTHREAD_VERSION'? There is a known bug affecting
the version of glibc that debian unstable comes with.
Lee
3:08 p.m.
On Thu, Sep 09, 2004 at 12:19:32AM -0400, Lee Revell wrote:
I'm in the habit of doing this on all the boxes I administer. It's
actually easier, imho, than the typical kernel build and easier to
manage different kernel versions. Unfortunately, I doubt my kernels will
be much use to anyone else as I tend to configure only the options I
need for my hardware. I don't even include stuff I have, but am not
using. For instance, there's no usb stuff in my kernel even though usb
is available on my mobo.
If I ever get my web/mail/icecast server finished and online I would not
mind at all building debs for others and making them available. I would
just need to get a standard .config from somewhere that would be likely
to work for most people. Building 2.6 kernels takes just over 4 minutes
on my audiobox. (The server's actually online, just not doing anything
... I changed registrars, still need to change the dns records and
coordinate shutting down the current hosting service, and, of course,
write some little python scripts to actually generate the html ... )
I think I mentioned earlier, but in case I didn't I'll say it again.
Other than the usual xruns when new clients connect, the xruns I'm
seeing aren't reported by jackd at all. I only see them from the
ecasound instance that is hosting the analogueOsc LADSPA plugins and
only when it exits. The rtnull input object reports them when this
ecasound instance exits. Every ecasound chain has to have an input and
an output. Since I just want the audio from the plugin, which in
ecasound's world is an effect attached to a chain between an input and
an output, the rtnull input object serves as a place holder virtual
audio device/file/thing.
Maybe these xruns are red herring? Kai?
On Wed, 2004-09-08 at 23:53, Eric Dantan Rzewnicki
wrote:
hmm, yeah, guess I just got lucky.
Lee Revell wrote:
Yeah, I know, but R9 had a bug
that caused it to not compile for me; R6
was the last version that worked. Maybe you are just not hitting that
bug... On Wed, 2004-09-08 at 17:38, Lee Revell wrote:
Well, actually there is an R9 out today ... I have it
patched, compiled and installed.
audiobox:~# uname -r
2.6.9-rc1-bk12-vp-r9
(had to lowercase the extraversion stuff to comply with debian policy
when making .deb with make-kpkg)
OK, great! I have been meaning to make .debs of
these but have not had
time. I've set
all the /proc and /sys stuff I could find in the wiki (console
output below). Still, I get xruns reported by my ecasound 8 analogueOsc
What other info should I provide?
All your settings look good. I think you are in
good shape. xruns are
normal when connecting and disconnecting a jack client, this does not
seem to hurt anything, and they should not happen once you are rolling. If you do get any xruns, here is how to debug them.
Reset the
preemption latency counter like this:
echo 0 > /proc/sys/kernel/preempt_max_latency
Then start jackd. When you see an xrun, copy the contents of
/proc/latency_trace to a file, then post them here.
I'll do this when I get home. Thanks.
Also, are you running debian unstable? What output do
you get when you
run 'getconf GNU_LIBPTHREAD_VERSION'? There is a known bug affecting
the version of glibc that debian unstable comes with.
Debian testing. How long has that been in unstable? Do you know if it
has migrated to testing, yet? I'm guessing not since they are trying to
get a release out and if the bug is still there I doubt they would move
it to testing.
Anyway, I'll check when I get home. I really ought to get my home
network in shape. There's no reason I shouldn't be able to check this
from here ... so many projects ... ah well.
Thanks,
Eric Rz.
5:58 p.m.
New subject: [ecasound] Re: [linux-audio-dev] Re: [Jackit-devel] Maybe I'm going at this wrong...?
Hello,
to avoid too heavy cross-posting, I dropped jackit-devel from the
cc-list...
On Thu, 9 Sep 2004, Eric Dantan Rzewnicki wrote:
seeing aren't reported by jackd at all. I only see
them from the
ecasound instance that is hosting the analogueOsc LADSPA plugins and
only when it exits. The rtnull input object reports them when this
ecasound instance exits. Every ecasound chain has to have an input and
an output. Since I just want the audio from the plugin, which in
ecasound's world is an effect attached to a chain between an input and
an output, the rtnull input object serves as a place holder virtual
audio device/file/thing.
Maybe these xruns are red herring? Kai?
Definitely! You should use "null" instead of "rtnull" if you have any
JACK, ALSA, or other real-time objects in the same setup.
Rtnull, or realtime null, consumes or produces data at real-time speed
(unlike plain "null" that does the same as fast as it can). This is useful
feature in some circumstances, for example when writing audio to a pipe
and from there with netcat to network. Without rtnull, you'd overflow the
network interface (and the receiving end).
But if you have both rtnull and jack/alsa devices in the same setup, you
will get xruns, as rtnull is driven by the system clock while jack/alsa
are driven by the soundcard clock. Sooner or later the clocks will drift
enough and you'll start to get constant xruns.
--
http://www.eca.cx
Audio software for Linux!
6:45 p.m.
New subject: [ecasound] Re: [linux-audio-dev] Re: [Jackit-devel] Maybe I'm going at this wrong...?
On Thu, Sep 09, 2004 at 10:41:34PM +0300, Kai Vehmanen wrote:
Hello,
to avoid too heavy cross-posting, I dropped jackit-devel from the
cc-list...
oops. <blush> sorry about that everyone. :(
On Thu, 9 Sep 2004, Eric Dantan Rzewnicki wrote:
Oh, good. Thanks for clarifying that. I have been wondering why a null
object would have trouble keeping up with making zeros. I'm sorry to
have misunderstood rtnull's purpose. :(
So it would seem that my audio glitches are indeed something in
ecasound, analogueOsc or somewhere in their interaction.
That's good news on the kernel side of things. Thanks Kai!
Lee, I'll still take a look at the stuff you mentioned earlier, just to
be sure. But, it looks like I don't have a kernel problem after all. So
this story turns from a possible trouble report to a positive audio user
experience report.
seeing aren't reported by jackd at all. I
only see them from the
ecasound instance that is hosting the analogueOsc LADSPA plugins and
only when it exits. The rtnull input object reports them when this
ecasound instance exits. Every ecasound chain has to have an input and
an output. Since I just want the audio from the plugin, which in
ecasound's world is an effect attached to a chain between an input and
an output, the rtnull input object serves as a place holder virtual
audio device/file/thing.
Maybe these xruns are red herring? Kai?
Definitely! You should use
"null" instead of "rtnull" if you have any
JACK, ALSA, or other real-time objects in the same setup.
Rtnull, or realtime null, consumes or produces data at real-time speed
(unlike plain "null" that does the same as fast as it can). This is useful
feature in some circumstances, for example when writing audio to a pipe
and from there with netcat to network. Without rtnull, you'd overflow the
network interface (and the receiving end). But if you have both rtnull and jack/alsa devices in
the same setup, you
will get xruns, as rtnull is driven by the system clock while jack/alsa
are driven by the soundcard clock. Sooner or later the clocks will drift
enough and you'll start to get constant xruns.
I was ready to take a look at the ecasound code tonight to see if I
could understand what the null-rtnull difference was ... I'm not sure I
could have figured it out on my own, but now I know. Thanks again.
btw, I'm still really having fun with the 8-oscillator thing. A bit of
it's output came up in one of my automated random mixes yesterday. It's
a sound resource I've been missing in my pool for a while and it's
really good to have that gap filled.
-Eric Rz.
6:19 a.m.
On Wed, Sep 08, 2004 at 11:53:48 -0400, Eric Dantan Rzewnicki wrote:
I've set all the /proc and /sys stuff I could find
in the wiki (console
output below). Still, I get xruns reported by my ecasound 8 analogueOsc
thingy. Interestingly, though, they now only happen when I start the
second ecasound process to record from the jack outputs of the first.
I'll double check that with previous kernel versions when I get a
chance, but I'm fairly sure this is new and an improvement.
jackd does not guarantee that you wont get XRUNs when you start jack apps,
it does some non-realtime things when you connect or disconnect apps.
Subjectively, the sound of the analogueOscs is
smoother and the zipper
noise from controller movements seems much less, but still the first
ecasound reports xruns when it exits.
Can you keep pestering me about that zipper noise bug? It wont take me
long to fix, I just need to remember it needs doing when I have free
time.
I really need to set up some kind of bugtracking thing for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind of modular wiki, so I can embedd a wiki
block in some online docs, with some way to indicate bugs, but the only
really modular one I've come across was written in JSP :(
- Steve
6:50 a.m.
On Thu, Sep 09, 2004 at 09:02:32AM +0100, Steve Harris wrote:
I really need to set up some kind of bugtracking thing for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind of modular wiki, so I can embedd a wiki
block in some online docs, with some way to indicate bugs, but the only
really modular one I've come across was written in JSP :(
OT, but what the hell ...
trac: http://www.edgewall.com/products/trac/
automatically tracks subversion, sets up bugtracking for your projects,
and ties the lot together with a wiki interface (eg. you can use
wikiwords in bug reports and their comments, including wiki-style links to
refer to code from specific svn revisions, etc. etc.). Absolutely rocks.
Written in python. Just Works.
to see what it's like, we've got one set up at annodex.net:
http://trac.annodex.net/index.cgi
cheers,
Conrad.
8:17 a.m.
On Thu, Sep 09, 2004 at 06:33:18PM +1000, Conrad Parker wrote:
On Thu, Sep 09, 2004 at 09:02:32AM +0100, Steve Harris
wrote:
Thanks, looks great. Will it let me (easily ie. automatically synced with
the source) create a seperate page for each plugin?
- Steve
I really need to set up some kind of bugtracking thing for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind of modular wiki, so I can embedd a wiki
block in some online docs, with some way to indicate bugs, but the only
really modular one I've come across was written in JSP :(
OT, but what the hell ...
trac: http://www.edgewall.com/products/trac/
automatically tracks subversion, sets up bugtracking for your projects,
and ties the lot together with a wiki interface (eg. you can use
wikiwords in bug reports and their comments, including wiki-style links to
refer to code from specific svn revisions, etc. etc.). Absolutely rocks.
Written in python. Just Works. 
3:13 p.m.
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
I really need to set up some kind of bugtracking thing
for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind of modular wiki, so I can embedd a wiki
block in some online docs, with some way to indicate bugs, but the only
really modular one I've come across was written in JSP :(
Mantis works fine for JACK and ardour.
Taybin set them both up, he could tell you how long it took.
--
joq
3:22 p.m.
On Thu, Sep 09, 2004 at 09:02:32AM +0100, Steve Harris wrote:
Will do. I'm going to slap together a non-realtime chain settup with
ecasound's builtin oscillator controllers instead of midi-controllers.
This will just print to a file, no realtime audio output, and will only
use ecasound and analogueOsc. So it should show if the audio glitches
and zipper noise are related to realtimeness or midi issues. I'll also
do a realtime version with ecasound's controllers.
I have vague memories of people saying on the alsa lists years ago that
ymfpci chips suck. I'm only using mine for a midi i/o. I happen to have
an es1370 sitting at home unused. Would it be worthwhile to stick that
in the box and see if the midi on that works any better? or is this
unlikely to be a midi problem at all?
On Wed, Sep 08, 2004 at 11:53:48 -0400, Eric Dantan
Rzewnicki wrote:
Thanks Steve. I understand that. The xruns when clients
connect/disconnect are actually the only ones jackd is reporting. The
others are reported by ecasound when it exits.
I've set all the /proc and /sys stuff I could
find in the wiki (console
chance, but I'm fairly sure this is new and an improvement.
jackd does not
guarantee that you wont get XRUNs when you start jack apps,
it does some non-realtime things when you connect or disconnect apps. Subjectively,
the sound of the analogueOscs is smoother and the zipper
noise from controller movements seems much less, but still the first
ecasound reports xruns when it exits.
Can you keep pestering me about that zipper
noise bug? It wont take me
long to fix, I just need to remember it needs doing when I have free
time. I really need to set up some kind of bugtracking thing
for swh-plugins,
but its not that easy, because of the hundreds of small lumps of code, and
installing and hacking something it will cut into valuable bugfixing time
:-/ I was hoping to use some kind of modular wiki, so I can embedd a wiki
block in some online docs, with some way to indicate bugs, but the only
really modular one I've come across was written in JSP :(
Well, maybe. I've wondered at times why there isn't a swh-ladspa mailing
list. I've never managed to get into wiki editing for various reasons. A
mailing list might be simpler to set up. If you want I could probably
host a mailman list on my server at home. Heck, we host the portaudio
list here at work, so I could probably convince the bossmen to host a
list for you, too. Just a thought. I suppose you would have already
been hosting a list yourself at plugin.org.uk if you wanted that.
-Eric Rz.
7178
days inactive
7178
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
7 participants
participants (7)
-
Conrad Parker -
Eric Dantan Rzewnicki -
Eric Dantan Rzewnicki -
Jack O'Quin -
Kai Vehmanen -
Lee Revell -
Steve Harris