Red Hat Bugzilla – Bug 133025
Sound-juicer hogs system ressources when ripping
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
My system slows to an absolute crawl when I rip cds with sound-juicer,
now I understand that it's a CPU and IO heavy job, but other rippers
do not slow my machine down to be pratically unusable.
I found that renicing the process to 10 improved the situation, but
that's just a hack-around.
According to an earlier attempt at getting Bastian to look at this:
He claims it's bad VM/IDE behavior, now if that is the case all my
machines display this problem, and everyone I've talked to basically.
I fear either Sound-juicer or gstreamer is causing this bad behavior,
so in an effort to get this fixed so everyone can go back to enjoying
their lifes and this fine piece of software.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Rip cd
Actual Results: watch system pratically lock up, extremely high
responsetime on any job.
Expected Results: Relatively normal use of the system being possible.
I don't think this bug has much to do with Fedora; we don't modify
sound-juicer, and it doesn't have much to do with the OS in general
except for our kernel.
Particularly if other rippers work fine, that would suggest to me that
it is an upstream sound-juicer issue. I've found a bug that seems
similar to this, I'm moving this there.
Since the post FC3 test2 update with the new sound-juicer and the new
kernel the issue seems far less intrusive - now only CDs that are
slightly damaged cause the system to become usuable for me.
Did the new kernel enable DMA or something because I can't find any
other explanation for this sudden improvement.