|
Ripping Audio CDs slows down the system seriously
During ripping Audio CDs with cdparanoia my system slows down painfully: Window Maker refreshes application's windows slowly, the content of the windows scrolls with resistance, mouse cursor moves stepwise etc. The problem appears in console mode as well. In Window Maker the command top shows that X uses up to 16% of CPU and cdparanoia up to 2%. In the console mode Midnight Commander uses up to 5% of CPU. I tested CD-ROM with hdparm -tT command. The results were about 1200 MB/sec of cached reads and 1.70 MB/sec of buffered disk reads. All these parameters seem to look reasonably so I don't understand why ripping affects the system in such way.
The above problem concerns my new machine with Intel Core Duo 1.83 GHz CPU and 1042 MB RAM. Surprisingly the system works much more smoother when running cdparanoia on my old machine with Intel Pentium M 1.5 GHz CPU and 512 MB RAM. The command top shows in that case that X uses up to 9% of CPU and cdparanoia up to 3.5%. In the console mode Midnight Commander uses up to 7.5% of CPU. In that case hdparm -tT command shows about 380 MB/sec of cached reads and 2.15 MB/sec of buffered disk reads. I switched CD-ROMs between these two machines and result was the same: new machine slows down significantly during ripping -- old machine works during ripping almost smoothly. On both machines I use Slackware 12.2 with generic 2.6.27.7-smp kernel. The system configuration is similar in both cases because both these machines are ThinkPads -- new one it's T60 and old one it's T40. The above problem concerns only ripping Audio CDs with cdparanoia. During ripping DVDs with mencoder the system works smoothly on both mentioned machines. I have no idea what's wrong with my new machine. Any help will be welcomed. |
I suppose I don't know the answer, but I'm willing to try to figure it out with you. First thing i'd do is to try a different cd-burning application and see what the differences are on the system level. So do
strace -T cdparanoia & Then strace -T OTHERCDBURN & and post what strace gives you, see if there is any significant differences. The T option will show the time spent in a system call, so if there is a large amount of time spent there, we can use that too. |
First I tested two commands:
strace -T cdparanoia -d /dev/cdrom -B 1 strace -T cdda2wav -D /dev/cdrom -x -paranoia -t 1 I suppose the latter is the equivalent of the former. When I used cdparanoia it slowed down the first machine. When I used cdda2wav it worked smoothly on both machines. I ripped first track from ``Dark Side of the Moon'' by Pink Floyd (``Speak to Me/Breathe''). That song lasts 3'57". For comparison I ripped that track on both machines with both mentioned programs. The output of strace -T is huge. Four outputs have together 1438216 bytes of size. It's impossible to put such big output in the message. Then I tested two other commands: strace -T cdparanoia -d /dev/cdrom -B 1 & strace -T cdda2wav -D /dev/cdrom -x -paranoia -t 1 & These two are exactly what you suggested in your message. In both cases strace displayed a lot of information but nor cdparanoia neither cdda2wav didn't read the Audio CD so I'm not sure these tests show valuable information. New machine strace -T cdparanoia -d /dev/cdrom -B 1 & Code:
write(2, "cdparanoia III release 10.2 (Sep"..., 49) = ? ERESTARTSYS (To be restarted) <0.000016>Code:
write(2, "Type: ROM, Vendor \'HL-DT-ST\' Mod"..., 70) = ? ERESTARTSYS (To be restarted) <0.000016>strace -T cdparanoia -d /dev/cdrom -B 1 & Code:
write(2, "cdparanoia III release 10.2 (Sep"..., 49) = ? ERESTARTSYS (To be restarted) <0.000010>Code:
write(2, "Type: ROM, Vendor \'MATSHITA\' Mod"..., 70) = ? ERESTARTSYS (To be restarted) <0.000009> |
Hm. Well, when you ran strace, did you notice it hanging at a certain time? cdparanoia is trying to access a resource that is being used frequently. Is cda2wav gui based? can you run cdparanoia without the gui? If you can, I would try that, to see if it is a specific aspect of the program, i.e., video. Have you checked cdparanoia's page, see if there are any reported bugs? I'll check it later on today too.
|
t 60
im using a t60, slackware 12.1 and the standard 2.6 kernel recompiled to throw out not used things.
at the moment i m using cdparanoia a lot because i have buyed some cds and didnt recognize in time that the output of lame is a terroristic attack to your ears (i was used to bladeenc, which produced hearable output, but is no longer developed) here cdparanoia is working fine without any problem. i know this is not really helpful but on some t60 machines cdparanoia is working normal. so it seems not to be a t60 special problem. did you try another cdrom drive in your machine maybe your new one is in some way broken, or use another cd i had problems with a 3 year old cdrom with music. campher |
cheftec:
When I ran strace with cdparanoia as well as with cdda2wav it displayed a lot of messages similar to these quoted in my previous post. It displayed them very fast so it's difficult to say if it did it smoothly but it seems to me that it worked without pauses in all cases. Both cdparanoia and cdda2wav are regular Linux text based commands. I ran all these commands directly without any GUI. I looked at http://www.xiph.org/paranoia/. I didn't find any bug report related to my problem but I found an interesting option: ``10.2 also includes a cache analysis option (-A) to do a slow an thorough offline check of the drive's cache behavior. The feature also dumps a detailed log to assist in debugging should either the test or cdparanoia's ripping go awry in any way. After all... better thoroughly safe than sorry''. I write about these tests below... campher: CD-ROM drive in my new machine is indeed invalid. It causes random problems when writing data, it can't read some DVDs, it works loudly, etc. I wrote about some of these problems in that thread: http://www.linuxquestions.org/questi...s-dead-691950/. I intend to call to service guys and ask them to replace my invalid combo drive. However the problem described in the present thread seems to be connected with machine and not with CD-ROM drive. As I mentioned in the first message I swapped CD-ROM drives between both these machines and the result was the same: cdparanoia affected the work of the system on the new machine and worked smoothly on the old one. I tested a lot of Audio CDs before I started that thread. My problem isn't related to some particular Audio CD. It occurs when I use my new machine. Option -A I checked both CD-ROM drives with cdparanoia -d /dev/cdrom -A command... cdparanoia -d /dev/cdrom -A # new machine Code:
cdparanoia III release 10.2 (September 11, 2008)Code:
cdparanoia III release 10.2 (September 11, 2008) |
You could try to run "hdparm /dev/cdrom" and "hdparm -i /dev/cdrom" on old and new machine and compare outputs. Also you could run same command on harddrive and compare outputs again.
Also you should probably check dmesg for suspicious messages (they might appear when you are ripping CDs). Also try to run ksysguard with default "graph" indicators - it will show cpu load in realtime, maybe (not sure about this, might be wrong) kernel wastes cpu time, not userspace program. |
Quote:
|
New machine
ThinkPad T60, Intel Core Duo 1.83 MHz CPU, 1024 MB RAM, 160 GB SATA HDD hdparm tests: Code:
root@home6:~# hdparm /dev/cdromCode:
user@home6:~$ vmstat 2ThinkPad T40, Intel Pentium M 1.50 MHz CPU, 512 MB RAM, 80 GB IDE HDD hdparm tests: Code:
root@home4:~$ hdparm /dev/cdromCode:
user@home4:~$ vmstat 2There are some differences in hdparm tests. New machine's CD-ROM has 0kB of BuffSize versus 512kB in the case of old machine's CD-ROM. New machine's HDD has 8192kB of BuffSize versus 0kB in the case of old machine's HDD. Because in the case of new machine's SATA HDD hdparm doesn't show that DMA is enabled, and I'm pretty sure it is, I did hdparm -tT tests to check the performances of both HDDs. I divided each vmstat test into three parts: before, during, and after running cdparanoia and lame. The more dramatical changes I observed during ripping and encoding in three cases: * io bo in the case of old machine jumps from 45-120 to 210-290 and in the case of new machine it jumps from 10-90 to 230-320. * system in in the case of old machine jumps from 290-320 to 280-320 and in the case of new machine it jumps from 600-660 to 210-660. * system cs in the case of old machine jumps from 1150-1600 to 950-1850 and in the case of new machine it jumps from 1850-2200 to 570-1720. Of course there are also big changes in the case of cpu us/sy/id tests but these parameters seem to achieve reasonable values. In the case of old machine cpu wa test rests on 0-4 level while in the case of new machine it jumps from time to time up to 15. I inspected dmesg during ripping Audio CD but it showed nothing interesting. I don't know how I can interpret these results. |
I just realized that in the above tests I ran simultaneously cdparanoia and lame in Window Maker. So I repeated these tests in the console mode running cdparanoia only.
new machine (before, during, and after ripping) Code:
user@home6:~$ vmstat 2Code:
user@home4:~$ vmstat 2In the case of old machine io bo and cpu wa jump significantly more frequently up then in the case of new machine. I have no idea what all that means. |
I compared WAV files produced by both cdparanoia and cdda2wav. In the case of most disks resulting files were identical. In the case of disks with Copy Control technology and in some other cases there were differences between files produced by these two programs but in such cases there were also differences between the same track ripped twice with the same program.
Then I compared MP3 files produced by lame with bitrate 160 to original Audio CD. I used my new machine and CD-ROM and amplifier by Marantz. I didn't hear any difference. Then I did the same test using my very old Toshiba Satellite and I noticed distinct differences. It leads to the conclusion that differences between better and worse sound cards are clearly audible while differences between good MP3 files and original Audio CDs are practically inaudible. Because I still don't know why cdparanoia affects the system in such serious manner in the case of my new machine I decided to use cdda2wav instead of cdparanoia. |
I just downgraded to Slackware's 12.1 cdparanoia-III10pre0 and it works much more fluently on my new machine -- almost the same as cdda2wav. So Slackware's 12.2 cdparanoia-III_10.2 has some bug that affects ThinkPad T60 though it don't affect ThinkPad T40.
|
cdparanoia 10.2 slows down the system on some machines
I just sent that bug report to paranoia@xiph.org:
cdparanoia-III_10.2 has difficult to identify bug that affects some machines. I tested it with Slackware 12.2 on two ThinkPads: T60 and T40. On the first machine new cdparanoia slows down the system seriously... Window Maker refreshes application's windows slowly, the content of the windows scrolls with resistance, mouse cursor moves stepwise etc. Similar problems occurs in the console mode. On the second machine new cdparanoia works almost fluently -- the same as cdda2wav. Then I downgraded from cdparanoia-III_10.2 to cdparanoia-III10pre0 and it worked on the first machine the same as on the second. So that bug appeared somewhere between 10pre0 and 10.2 versions of cdparanoia and it affects some machines (for example ThinkPad T60) but doesn't affect other ones (for example ThinkPad T40). At the end I compared versions 10.2 and 10pre0 of cdparanoia on the same ThinkPad T60 using vmstat... Vmstat report before, during, and after ripping Audio CD with cdparanoia-III_10.2: Code:
$ vmstat 2Code:
$ vmstat 21. 10.2 uses slightly more memory than 10pre0. 2. 10.2 has system in about 150-185 while 10pre0 about 355-420. 3. 10.2 has system cs about 65-90 while 10pre0 about 90-130. 4. 10.2 has cpu us about 0-6 while 10pre0 about 0-1. 5. 10.2 has cpu sy about 25-35 while 10pre0 about 10-25. 6. 10.2 has cpu id about 65-70 while 10pre0 about 75-85. 7. 10.2 has cpu wa about 0-2 while 10pre0 about 0-3. I don't know how I can interpret these values. |
| All times are GMT -5. The time now is 01:28 AM. |