Version: (using KDE KDE 3.3.2) Installed from: SuSE RPMs OS: Linux I can't really burn audio CDs in 48x speed with my LiteOn drive. At 12x, CPU load is around 50%, at 16x it is at 80%, and with higher values, the burning process is delayed due to "buffer underruns" (which are not that bad because of "burnfree"). The same happens when burning BIN/CUE. I think this should not happen on an Athlon XP 2000, since burning Data CDs with 48x speed takes almost no CPU usage. Playing MP3s does not either, so decoding MP3s should not be too CPU intensive. Also burning audio CDs from MP3s works with almost no CPU usage when I am using typical Windows software, so this should be possible in principle. Any ideas?
I have the same problem. When I write a disk, the system load sky rockets. Top shows that it is kicker that begins using all CPU available. Reniceing it, enables the write process to finish, but the kicker will still use at least 50-60% of the cpu. Once k3b is done, everything returns to normal...
I have the same problem with SuSE 3.3.2 RPMs for SuSE 9.1 But I cannot confirm that it's kicker... top shows me that it's k3b for sure which causes this incredible load. I use an Athlon XP 2800+ and burning 52x data CDs has CPU usage of about 3% (I think most of it is the rapid update of the status information)... 16x is the highest speed I can use to burn audio CDs from mp3 without causing burn-free to activate... There seems to be a real bug in the mp3 decoding routine... To compare it to another mp3 decoder: > time mpg321 Track\ 01.mp3 -s >/dev/null High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3. Version 0.59q (2002/03/23). Written and copyrights by Joe Drew. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Title : Track 01 Artist: Unknown Album : Unbekannte CD Year : Comment: Genre : Alternative Playing MPEG stream from Track 01.mp3 ... MPEG 1.0 layer III, 192 kbit/s, 44100 Hz joint-stereo [3:24] Decoding of Track 01.mp3 finished. real 0m3.489s user 0m3.149s sys 0m0.035s So the k3b behavior cannot be normal. Daniel
Just did some measurements and saw that the hardware interrupt value shown by 'top' is at 45% while burning an audio CD with 10x. This bug is not related to MP3 decoding and probably not a problem of k3b.
More information can be found at http://sourceforge.net/mailarchive/forum.php?thread_id=6260166&forum_id=1927
I get the same (even worse) statistics as Rüdiger. But when switching over to RAW mode burning, all is fine. So it has to be cdrecord or the linux ATAPI implementation or a combination of both. So k3b has dropped out it seems :) But where to go next with this problem? To Jörg Schilling? I have the feeling that Jörg is not into giving support as much as in the past.... But we could try.... Any suggestions?
There was a problem with older k3b versions that updated the progress bars way too often. Do you still get the problem with k3b 0.12.7? If not, please close this bug report.
No, that problem still persists with k3b 0.12.7 on my machine. And still RAW mode magically solves all problems. By the way: To test this, I simulated DAO burn and then I simulated RAW burn. After the RAW simulation, the medium was not empty anymore. RAW mode simulating seems not to be just simulating... Should I file this as a new bug? Or is this a known limitation of cdrecord? In this case it should warn, that it might not just be simulating the burn.....
please file it as a new bug. k3b should warn about that. I am just not sure if it's a cdrecord limitation, a limitation of certain writers or all writers...
According to the mailing list thread in comment #4 the kicker problem might have been fixed and Sebastian comment that it should be fixed in 0.12.7. The problem about a high hardware interrupt load is not necessarily k3b related.
If using RAW writing mode solves the issue this is not a K3b problem. the system load is more likely caused by cdrecord or the kernel. Checking that should be fairly simple.