13 Jan
2010
13 Jan
'10
9:39 p.m.
I've been running Fons's great Auto-Wah on my 32-bit Netbook for many months now,
using it live constantly, and I love it.
I'm going into the studio Friday, so I've dusted off my 64-bit Core 2 Duo system
and putting it through its paces.
Turns out that on my Core2Duo, JACK RACK running Fons's auto-wah plugin sucks up 6%
CPU even if there is no sound going through it.
I asked Fons about it; he can't duplicate the problem since he doesn't have a
64-bit system. Hell, I can't even duplicate it on my 32-bit system; it's 64-bit
dependent.
I looked at the output with Bitmeter at Fons' suggestion, and it seems there are no
denormals, inf's, or nans-- just a very small -230dB DC offset in the code (probably
to avoid denormals).
The CPU usage ramps up before any signal is fed into the plugin. It runs normally when
there is signal, but then it keeps sucking up CPU afterwards. I'm feeding it from
fluidsynth, and bitmeter says that it isn't sending anthing at all during silent
moments.
It doesn't run away to 99% CPU (or 50% on a Core2Duo), like it would if there were a
denormal. But still, why is it using up CPU when there's no signal? That seems odd.
And why only on my 64-bit machine? FWIW, the 64-bit and 32-bit machines I have are even
running the same kernel and RT-patch versions (2.6.26.8-rt12).
Can someone with a 64-bit system help me by trying to duplicate the problem? I'm
looking to see if JACK-RACK running just Fons' plugin uses as much CPU with silence as
when there's signal running through it.
Oh, and in case it's setting-dependent, here is the rack with the settings I'm
using:
http://restivo.org/misc/clavy-phaser.rack
-ken
14 Jan
14 Jan
5:21 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Thursday 14 January 2010 02:38:04 Ken Restivo wrote:
Turns out that on my Core2Duo, JACK RACK running
Fons's auto-wah plugin
sucks up 6% CPU even if there is no sound going through it.
I asked Fons about it; he can't duplicate the problem since he doesn't have
a 64-bit system. Hell, I can't even duplicate it on my 32-bit system; it's
64-bit dependent.
I looked at the output with Bitmeter at Fons' suggestion, and it seems
there are no denormals, inf's, or nans-- just a very small -230dB DC
offset in the code (probably to avoid denormals).
The CPU usage ramps up before any signal is fed into the plugin. It runs
normally when there is signal, but then it keeps sucking up CPU
afterwards. I'm feeding it from fluidsynth, and bitmeter says that it
isn't sending anthing at all during silent moments.
It doesn't run away to 99% CPU (or 50% on a Core2Duo), like it would if
there were a denormal. But still, why is it using up CPU when there's no
signal? That seems odd. And why only on my 64-bit machine? FWIW, the
64-bit and 32-bit machines I have are even running the same kernel and
RT-patch versions (2.6.26.8-rt12).
Here is a shot:
Maybe the 64bit is better at calculation and -230dB are not yet good enough to
avoid denormals. What if you change that code to add a bit more offset?
Or use it in an ardour session for testing and try the different denormal modes
of ardour to see if one helps...
Have fun,
Arnold
7 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU?usage?
On Thu, Jan 14, 2010 at 10:20:57AM +0100, Arnold Krille wrote:
Maybe the 64bit is better at calculation and -230dB
are not yet good enough to
avoid denormals. What if you change that code to add a bit more offset?
The code adds 1e-10f (-200dB) to the input of the first
delay element in a 2nd order allpass filter. How much
of this remains at other points depends on the filter
parameters, but it won't go much below -230dB. And that
is giant overkill already. Denormals for 32-bit FP are
below -750dB.
Ciao,
--
FA
5:43 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Wed, Jan 13, 2010 at 05:38:04PM -0800, Ken Restivo wrote:
It doesn't run away to 99% CPU (or 50% on a
Core2Duo),
like it would if there were a denormal. But still, why
is it using up CPU when there's no signal?
That's not as odd as it seems: there is *always* a signal,
even if that signal happens to be silence, and while the
actual processing parameters depend on signal level, the
algorithm itself is always the same. It could be optimised
for 'silence' by removing the per-sample interpolation of
the filter parameters when those are static, but I don't
think that would be worth the effort.
That said, 6% seems too much.
Ciao,
--
FA
6:41 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
Excerpts from Ken Restivo's message of Thu Jan 14 02:38:04 +0100 2010:
I've been running Fons's great Auto-Wah on my
32-bit Netbook for many months
now, using it live constantly, and I love it.
I'm going into the studio Friday, so I've dusted off my 64-bit Core 2 Duo
system and putting it through its paces.
Turns out that on my Core2Duo, JACK RACK running Fons's auto-wah plugin sucks
up 6% CPU even if there is no sound going through it.
I asked Fons about it; he can't duplicate the problem since he doesn't have a
64-bit system. Hell, I can't even duplicate it on my 32-bit system; it's 64-bit
dependent.
I looked at the output with Bitmeter at Fons' suggestion, and it seems there
are no denormals, inf's, or nans-- just a very small -230dB DC offset in the
code (probably to avoid denormals).
The CPU usage ramps up before any signal is fed into the plugin. It runs
normally when there is signal, but then it keeps sucking up CPU afterwards. I'm
feeding it from fluidsynth, and bitmeter says that it isn't sending anthing at
all during silent moments.
It doesn't run away to 99% CPU (or 50% on a Core2Duo), like it would if there
were a denormal. But still, why is it using up CPU when there's no signal? That
seems odd. And why only on my 64-bit machine? FWIW, the 64-bit and 32-bit
machines I have are even running the same kernel and RT-patch versions
(2.6.26.8-rt12).
Can someone with a 64-bit system help me by trying to duplicate the problem?
I'm looking to see if JACK-RACK running just Fons' plugin uses as much CPU with
silence as when there's signal running through it.
Oh, and in case it's setting-dependent, here is the rack with the settings I'm
using:
http://restivo.org/misc/clavy-phaser.rack
-ken
Hi Ken.
I'm on 64 bit, so I thought I give it a shot, however, my 64 bit system
is a bit unusual since it's only a single core celeron.
The result is vastly different from yours, cpu usage of jack-rack in
htop is 0.0% most of the time, occasionally it shows 1.0%, so not even
when running it shows the 6% you get.
I only give it some webradio from mplayer, and it doesn't seem to matter
whether it's playing or not or whether it's connected, it's all the
same. I was clever enough to enable the plugin in jack-rack.
What I do get around 6% is mem usage (out of 1GB).
Hope that helps.
Regards,
Philipp
1:49 p.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Thu, Jan 14, 2010 at 11:41:26AM +0100, Philipp ??berbacher wrote:
Excerpts from Ken Restivo's message of Thu Jan 14
02:38:04 +0100 2010:
What are your JACK period settings? Is it less than 64? Mine are
-R -P70 -dalsa -X seq -r48000 -p128 -n3 -Phw:1,0 -Chw:1,1
Fons' code is like a finely-crafted jewel, and it is written in a terse style that
looks to me like hand-optimised ASM code (i.e., variable names that are more like register
names: "_s1", "gy", "dx"), but I'm starting to
understand it a little bit.
It looks like he's windowing through the frames, and if the frame is > 80 bytes, he
windows through it in 64-byte increments. I am using 3 periods of 128bytes each.
-ken
I've been running Fons's great Auto-Wah
on my 32-bit Netbook for many months
now, using it live constantly, and I love it.
I'm going into the studio Friday, so I've dusted off my 64-bit Core 2 Duo
system and putting it through its paces.
Turns out that on my Core2Duo, JACK RACK running Fons's auto-wah plugin sucks
up 6% CPU even if there is no sound going through it.
I asked Fons about it; he can't duplicate the problem since he doesn't have a
64-bit system. Hell, I can't even duplicate it on my 32-bit system; it's 64-bit
dependent.
I looked at the output with Bitmeter at Fons' suggestion, and it seems there
are no denormals, inf's, or nans-- just a very small -230dB DC offset in the
code (probably to avoid denormals).
The CPU usage ramps up before any signal is fed into the plugin. It runs
normally when there is signal, but then it keeps sucking up CPU afterwards. I'm
feeding it from fluidsynth, and bitmeter says that it isn't sending anthing at
all during silent moments.
It doesn't run away to 99% CPU (or 50% on a Core2Duo), like it would if there
were a denormal. But still, why is it using up CPU when there's no signal? That
seems odd. And why only on my 64-bit machine? FWIW, the 64-bit and 32-bit
machines I have are even running the same kernel and RT-patch versions
(2.6.26.8-rt12).
Can someone with a 64-bit system help me by trying to duplicate the problem?
I'm looking to see if JACK-RACK running just Fons' plugin uses as much CPU with
silence as when there's signal running through it.
Oh, and in case it's setting-dependent, here is the rack with the settings I'm
using:
http://restivo.org/misc/clavy-phaser.rack
-ken
Hi Ken.
I'm on 64 bit, so I thought I give it a shot, however, my 64 bit system
is a bit unusual since it's only a single core celeron.
The result is vastly different from yours, cpu usage of jack-rack in
htop is 0.0% most of the time, occasionally it shows 1.0%, so not even
when running it shows the 6% you get.
I only give it some webradio from mplayer, and it doesn't seem to matter
whether it's playing or not or whether it's connected, it's all the
same. I was clever enough to enable the plugin in jack-rack.
What I do get around 6% is mem usage (out of 1GB).
2:12 p.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Thu, Jan 14, 2010 at 09:48:08AM -0800, Ken Restivo wrote:
Fons' code is like a finely-crafted jewel, and it
is written
in a terse style that looks to me like hand-optimised ASM code
(i.e., variable names that are more like register names:
"_s1", "gy", "dx"), but I'm starting to understand it a
little bit.
It's not ASM style, it's mathematical notation.
It looks like he's windowing through the frames,
and if the
frame is > 80 bytes, he windows through it in 64-byte
increments.
That's something you'll find in many of my plugins.
Its purpose is to normally have a block size of 64 frames,
but avoid a very short (e.g. one frame) final block when
'nframes' can take arbitrary values, as could happen when
parameters are automated and a host wants to update them
in the middle of a period.
while (nframes)
{
k = (nframes < 80) ? nframes : 64;
// Process k frames, 16 <= k <= 64
nframes -= k;
}
With your Jack settings the result will normally be two
blocks of 64 frrames. Filter paramters are updated at
block rate, with linear interpolation in between.
Ciao,
--
FA
15 Jan
15 Jan
5:29 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Thu, Jan 14, 2010 at 07:08:26PM +0100, fons(a)kokkinizita.net wrote:
On Thu, Jan 14, 2010 at 09:48:08AM -0800, Ken Restivo
wrote:
OK I tried a hack to check at the beginning of each process callback whether all the bytes
in the buffer add up to 0, and then just return instead of going through the rest of your
filter algorithm. And...
Your code is so efficient that after I added my little two-line hack, it made the problem
WORSE! 10% CPU instead of 6%.
I'm just shaking my head over here. I have no idea what is going on.
Oh, and on a different topic, I did get my FastTrack Pro to run at 24bits. I just had to
add the following to /etc/modprobe.d/sound: options snd-usb-audio device_setup=0x9
enable=1 The parameters did NOT get 24-bit mode going when given on the modprobe command
line, but they DID work when added to modprobe.d. I suspect some kind of weird udev or hal
magic going on.
Recording a band tomorrow. Alas, the tracking will be on ProTools, but the editing,
overdubbing, and mixing will now be in Ardour. Yay!
-ken
Fons' code is like a finely-crafted jewel,
and it is written
in a terse style that looks to me like hand-optimised ASM code
(i.e., variable names that are more like register names:
"_s1", "gy", "dx"), but I'm starting to understand it a
little bit.
It's not ASM style, it's mathematical notation.
It looks like he's windowing through the
frames, and if the
frame is > 80 bytes, he windows through it in 64-byte
increments.
That's something you'll find in many of my plugins.
Its purpose is to normally have a block size of 64 frames,
but avoid a very short (e.g. one frame) final block when
'nframes' can take arbitrary values, as could happen when
parameters are automated and a host wants to update them
in the middle of a period.
while (nframes)
{
k = (nframes < 80) ? nframes : 64;
// Process k frames, 16 <= k <= 64
nframes -= k;
}
With your Jack settings the result will normally be two
blocks of 64 frrames. Filter paramters are updated at
block rate, with linear interpolation in between.
7:10 a.m.
New subject: Sanity check needed: Fons's Auto Wah on 64-bit system and CPU usage?
On Fri, Jan 15, 2010 at 01:27:52AM -0800, Ken Restivo wrote:
I'm just shaking my head over here. I have no
idea what is going on.
One thing you could try is this:
void Ladspa_Autowah::runproc (unsigned long len, bool add)
{
+ memcpy (_port [A_OUT], _port [A_INP], len * sizeof (float));
+ return;
int i, k;
float *inp = _port [A_INP];
float *out = _port [A_OUT];
...
}
This will just copy the input to the output. If this gives
non-trivial CPU load, something else (outside this plugin)
is going wrong.
Ciao,
--
FA
5621
days inactive
5623
days old
linux-audio-user@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Arnold Krille -
fons＠kokkinizita.net -
Ken Restivo -
Philipp Überbacher