SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Rep:
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.
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.
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.
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.
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.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Original Poster
Rep:
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)
Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/cdrom for cdrom...
Testing /dev/cdrom for SCSI/MMC interface
SG_IO device: /dev/hda
CDROM model sensed sensed: HL-DT-ST DVDRAM GSA-4083N 1.08
Checking for SCSI emulation...
Drive is ATAPI (using SG_IO host adaptor emulation)
Checking for MMC style command set...
Drive is MMC style
DMA scatter/gather table entries: 1
table entry size: 131072 bytes
maximum theoretical transfer: 55 sectors
Setting default read size to 27 sectors (63504 bytes).
Verifying CDDA command set...
Expected command set reads OK.
Attempting to set cdrom to full speed...
drive returned OK.
=================== Checking drive cache/timing behavior ===================
Seek/read timing:
[42:41.27]: 49ms seek, 1.60ms/sec read [8.3x]
[40:00.33]: 50ms seek, 1.61ms/sec read [8.3x]
[30:00.33]: 57ms seek, 1.61ms/sec read [8.3x]
[20:00.33]: 54ms seek, 1.60ms/sec read [8.3x]
[10:00.33]: 61ms seek, 1.60ms/sec read [8.3x]
[00:00.33]: 74ms seek, 1.61ms/sec read [8.3x]
Analyzing cache behavior...
Approximate random access cache size: 16 sector(s)
Drive cache tests as contiguous
Drive readahead past read cursor: 234 sector(s)
Cache tail cursor tied to read cursor
Cache tail granularity: 1 sector(s)
Cache read speed: 0.19ms/sector [70x]
Access speed after backseek: 2.14ms/sector [6x]
Backseek flushes the cache as expected
Drive tests OK with Paranoia.
cdparanoia -d /dev/cdrom -A # old machine
Code:
cdparanoia III release 10.2 (September 11, 2008)
Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/cdrom for cdrom...
Testing /dev/cdrom for SCSI/MMC interface
SG_IO device: /dev/hdc
CDROM model sensed sensed: MATSHITA UJDA755zDVD/CDRW 1.20
Checking for SCSI emulation...
Drive is ATAPI (using SG_IO host adaptor emulation)
Checking for MMC style command set...
Drive is MMC style
DMA scatter/gather table entries: 1
table entry size: 131072 bytes
maximum theoretical transfer: 55 sectors
Setting default read size to 27 sectors (63504 bytes).
Verifying CDDA command set...
Expected command set reads OK.
Attempting to set cdrom to full speed...
drive returned OK.
=================== Checking drive cache/timing behavior ===================
Seek/read timing:
[42:41.27]: 39ms seek, 0.80ms/sec read [16.7x]
[40:00.33]: 39ms seek, 0.80ms/sec read [16.7x]
[30:00.33]: 33ms seek, 0.90ms/sec read [14.9x]
[20:00.33]: 46ms seek, 1.01ms/sec read [13.2x]
[10:00.33]: 38ms seek, 1.20ms/sec read [11.1x]
[00:00.33]: 51ms seek, 1.58ms/sec read [8.5x]
Analyzing cache behavior...
Approximate random access cache size: 4 sector(s)
Drive cache tests as contiguous
Drive readahead past read cursor: 683 sector(s)
Cache tail rollbehind: 3 sector(s)
Cache tail granularity: 1 sector(s)
Cache size (considering rollbehind) too small to test cache speed.
Drive tests OK with Paranoia.
According to these tests the drive in my new machine works slower in some cases then in the old one however I don't know how to interpret these results.
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.
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.
There 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.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Original Poster
Rep:
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.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Original Poster
Rep:
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.
Distribution: Slackware (personalized Window Maker), Mint (customized MATE)
Posts: 1,309
Original Poster
Rep:
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-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:
1. 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.