Skip to Content

100% cpu with hydrogen svn 0.9.4-101

16 replies [Last post]
Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

I compiled the latest svn version, no problems there, but when I start playing (I use hydrogen to trigger sounds from a drum module) cpu usage soon shoots up to 100%, rendering it unusable, while with the 0.9.3 version it seldom goes past 10%, no matter how wildly I play. Could this be a bug, or something I did wrong?

Hydrogen rocks! but I'm just dying to use the new 'mute group' function...

Regards

yervah
Offline
Joined: 04/17/2010

I just installed hydrogen svn 0.9.4-112. that works fine with low cpu usage.

Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

OK, I installed 0.9.4-svn112 and it works much better, though cpu usage for some reason still climbs too high (now rarely reaches 100%, but sometimes comes close) and the sound gets a bit crackled now and then.

Thanks.

wolke
wolke's picture
Offline
Joined: 03/30/2010

did you get the crackled sound with 0.9.3 too?
Are you shure that this effect is an new one?
What type of sondfiles you use? (flac wav aiff)

Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

With 0.9.3 sound and performance is perfect and cpu usage hardly ever goes beyond around 10%, so yes, this behaviour is new.

I'm using .wav and flac files, with exactly the same setup as with 0.9.3

When I made my previous post I was checking it out on the keyboard; when I tried it out playing through the drum module crackling became unbearable in a question of seconds.

Any thoughts?

Cheers

mauser
Offline
Joined: 03/30/2010

Hey,

thanks for your bugreport! Since i'm the one who made the last changes to hydrogen-svn, i'm very interested :) I can't reproduce that behaviour here (Thinkpad 1,4GHZ,2GB Ram, Debian, Jack, No RT), cpu usage goes never beyond 10%.. Could you describe your system a little bit? What happens if you just start hydrogen without doing anything?

Thanks,
Sebastian

wolke
wolke's picture
Offline
Joined: 03/30/2010

hello,

i have the same crackle with some Kits.!
Specifically with Flac based Sets like the Roland TR-707.
I have opend the files with Audacity and see a big DC offset.
Remove this offset and some "fade outs" on the end of the samples help. After this work no more crackle with the Set.

I test this with h2 0.9.4svn85 and 0.9.4svn112.
The same result,

system:
Debian unstable with RT kernel.
Older P IV Notebook with 512 mb ram.

Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

Hi

I have a Compaq Presario 1'86 GHZ, 2GB ram running with Ubuntu 7.10; RT kernel, jack, and crappy onboard HDA intel soundcard - though it's been working more or less fine till now (sound is rubbish but it 'delivers').

When I start hydrogen and it's idle, it's OK, nice and calm. As soon as I start playing the cpu bar makes a steady climb and in about 5 secs it's unplayable.

Hope this helps

wolke
wolke's picture
Offline
Joined: 03/30/2010

I have a second notebook with analog devices based HDA-intel soundcard. It's a thinkpad R61 . With the kernel based Alsa-Driver I get a lot of Xruns and high dsp-load with jackd and hydrogen. I patched the 2.6.23 kernel sources with this alsa patch (alsa-git-2008-01-31.patch.gz) then I apply the RT-Patch. After compiling and installing this kernel. I get lower dsp-load and less xruns with my AD based HDA Intel soundcard.

For more information about HDA Intel Soundcards take a look into the Thinkwiki

With the Ubuntu RT-Kernel I always get bad results. I don't know why.
I always get he best Audio performance with Debian unstable + RT Patch and RT-IRQ Script.

yervah
Offline
Joined: 04/17/2010

yeah, I get lots of xruns too. I get the crackled noise also. cpu not as good as 10% but no way as high as 100%.
I got both 9.3 and 9.4-svn112 using ArchLinux with RT and jackd. AMD 1.7, 1 GB ram.
when I run 9.4-svn112 with Ardour, then the cpu usage hits100% but with 9.3 and Ardour, no issues.

Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

If I use the default kit it's OK, no xruns or crackles, but if I try to load a kit using .wavs or flacs (more than 1 layer) it can't handle it.

wolke
wolke's picture
Offline
Joined: 03/30/2010

Hello,
I have tried to narrow down the problem.
1. I found out that DC offset in samples like the Roland TR-707 Snare2 produce distortions if the samples are overlap (fast play or Simultaneous play).
2. Long flac samples tend to produce crackles.The long flac samples crackle less than if they are not driven up. That means normalization with -6dB help here. Of corse remouve DC offset.
3. The master volume fader as far to cut, that just yellow LED lights. In order to prevent an override.
4. I get only 100% dsp-load and xruns if I override ladspa plugins

.I test this with hydrogen 0.9.4svn85 on Debian unstable, rt-kernel and rme cardbus + multiface.
Hydrogen + ardour make no problems.

DC OFFSET is always bad. By overlapping the samples offset can be added. With a high offset some hardware and sound driver can get a lot of problems with it.

DrG
Offline
Joined: 04/17/2010

If the samples in your drum kit are very long and you play a lot of them quicky this will cause very high CPU usage because the next hit does make the previous one stop. Does the same behaviour occur if you just play one or two hits slowly?

It's definitely going to be worse with FLAC samples because there is uncompresing to do, and it will also be worse if your samples are not the same sample rate as JACK is using.

I use 48KHz on my sound card and I get much better performance by only using 48KHz WAV samples in my drumkits.

My modification to make JACK track outputs work more like you would expect will also increase the CPU usage by a small amount. I believe this is in SVN now. Maybe we need another option to disable track outputs?

Ignotus
Ignotus's picture
Offline
Joined: 05/14/2010

Hi

I tried out svn-136 with a clean 8.04 Hardy install and now it works perfect for me, no xruns in jack nor high cpu load in hydrogen. I'd tried some of the above approaches but with no luck, and a clean installation sorted it out, no special tweaking with samples to get it behaving properly. Maybe I'd clogged something up in my previous setup (I'm a noob who messes around an awful lot, sometimes too much...) .

Cheers!

mauser
Offline
Joined: 03/30/2010

@DrG: Configurable track outs are in svn (again). Thanks to wolke! (Btw. he told me that the dsp load got reduced by an amount of 20-30% with disabled track outs..

DrG
Offline
Joined: 04/17/2010

@mauser: I can well believe it. There is a great deal more work to do with the track outs enabled. Actually I doubt that there's much difference between pre- and post- fader, but what increased the load was the need to make them act like the main outs in terms of not chopping the end of one sample off when another is played. It means that all track output buffers have to be initialised every time the oputputs are refreshed. I believe it's this one small fact that has increased the dsp load. If anyone can find a more efficient method of doing it than the way I chose, I urge them to put it in! :)

fuzzix
Offline
Joined: 04/17/2010

Hi ignotus.

Having precisely the same problem here. A little research leads me to believe it's a Qt4 issue! (Strange, I know).

http://lists.linuxaudio.org/pipermail/linux-audio-user/2008-March/052063...
http://preview.tinyurl.com/5lv2lk
http://www.mythtv.org/pipermail/mythtv-users/2008-March/217837.html

I might have a play around with Qt build options tomorrow and check out the latest hydrogen - see what happens :)

An aside; I get 100% CPU use with qjackctl too - the jack daemon itself uses negligible CPU time. Qt4 suspected as well :)