Ripping audio CD is REALLY slow on Fedora 16

[CrazyCaver]

After upgrading to Fedora 16, I find that ripping audio CDs is REALLY slow. On Fedora 15 it would take around 3 minutes to rip a 45 minute CD. On Fedora 16 the same job takes 30 to 40 minutes.

I used preupgrade to get from Fedora 15 to Fedora 16. I also moved to a new computer which is faster and has more memory than the old. The optical drive is the same model.

This is all 64-bit. CPU usage while ripping is in the range of 3 to 6 percent.

I use k3b to do the ripping. I tried some other tools, but they are also really slow. cdda2wav, for example, is no faster.

Burning an audio CD runs very fast, so I am reasonably sure there is not a hardware or driver problem.

Any ideas?

Thanks - Bill Gee

[flyingfsck]

There is a general I/O speed problem starting with Fedora 15. Please file a bug report on this latest regression.

[smr54]

Any machine available for a fresh install? (Even a minimal quick install, and then install cdrtools). Then, you could do a quick check and see if the problem is F16 or just something that got messed up during pre-upgrade.

It may be the cpu scaling thing.

http://forums.fedoraforum.org/showthread.php?t=272109

[neur0]

I can confirm this.
Haven't installed Fedora before (fresh install - x64 - using Asunder).

PS hello forum!

[CrazyCaver]

Hello everyone - Thanks for the suggestions. I tried a few things, but no luck so far.

1) I went into the BIOS and disabled Intel EIST.

2) I edited /etc/sysconfig/cpupower to have "performance" as the driver on all lines.

# See 'cpupower help' and cpupower(1) for more info
CPUPOWER_START_OPTS="frequency-set -g performance"
CPUPOWER_STOP_OPTS="frequency-set -g performance"

3) I edited the scaling-governor files under each CPU. They all read "performance" now.

4) cpupower frequency-info now gives this information:

[root@main2 sysconfig]# cpupower frequency-info
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  boost state support:
    Supported: yes
    Active: yes
    2200 MHz max turbo 4 active cores
    2200 MHz max turbo 3 active cores
    2500 MHz max turbo 2 active cores
    2500 MHz max turbo 1 active cores

The processor is an Intel i5-760 on a SuperMicro C7SIM-Q mainboard.

After steps 1 through 4, I rebooted.

5) I do not have another system where I can do a clean install. I can build VirtualBox systems, but I don't think that will help diagnose this problem. My VirtualBox host is the same mainboard with an i7 processor and Fedora 15. I am disinclined to upgrade it to F16 ... This system will rip audio CD at full speed, but it is very inconvenient to use it because it does not have a good connection to the final storage location for the ripped files. I have to copy gigabytes of stuff up to a server temp dir, then down to a workstation.

6) Yesterday I ran "yum update" and took everything it offered. I am running the latest kernel. The update did not improve the speed of ripping.

Bill Gee

[smr54]

It seems that a fresh install wouldn't make a difference, judging from neur0's post.

I don't know enough about the CPU scaling stuff to judge whether your results indicate that you've eliminated it as a factor--I just remember RupertPupkin saying that he was unable to disable it without rebuilding the kernel.

[RupertPupkin]

It could be the cpu scaling issue. Check the output of this command: grep MHz /proc/cpuinfo

CD ripping can be slow if DMA has somehow been disabled on the CDROM drive. Check the output of this command: dmesg | grep -i dma

On my F16 x86_64 system with a single-core AMD64 3700+ 2.2GHz cpu, I can rip an entire 77-minute music CD (ABBA Gold ) in less than 3 minutes:

$ time cdparanoia -B -Y -Z
cdparanoia III release 10.2 (September 11, 2008)
...
real    2m41.808s
user    0m0.944s
sys     0m2.922s

That ripped all 19 tracks from the CD in WAV format.

[neur0]

I disabled cool'n'quiet and my proc/cpuinfo no longer shows 800 per core, but the normal 2.8Ghz, but ripping is still nowhere near as fast as expected. It's more like 5-10 min/track.
I don't think it's an encoding issue, but I will try pure file to file encoding when I get back home.

[CrazyCaver]

Hi RupertPupkin -

"dmesg | grep dma" shows the following output:

[root@main2 temp2]# dmesg | grep dma
[    0.502435] pnp 00:02: [dma 4]
[    0.502699] pnp 00:06: [dma 0 disabled]
[    0.502916] pnp 00:07: [dma 0 disabled]
[    3.143798] ata7: PATA max UDMA/100 cmd 0xbc00 ctl 0xb880 bmdma 0xb400 irq 18
[    3.143891] ata8: PATA max UDMA/100 cmd 0xb800 ctl 0xb480 bmdma 0xb408 irq 18
[   28.427210] /usr/sbin/crond[1028]: (CRON) INFO (Syslog will be used instead of sendmail.): No such file or directory

If DMA were disabled on the optical drive, I would think that burning would also be slow. It's not - burning runs at better than 30x. A 60 minute audio CD will burn in about 3 minutes with CPU running under 10% utilization. Most of that usage is probably from converting flac to wav on the fly as it burns the CD.

I don't know what the PATA stuff is for. The mainboard has a PATA interface but nothing is hooked to it. Both the hard drive and the optical drive are connected by SATA, and I set the SATA mode to AHCI in the BIOS. it is not using emulation.

Bill Gee

---------- Post added at 08:18 PM ---------- Previous post was at 06:43 PM ----------

Update -

I think I found an interesting, if kludgy, way to make the rips runs fast. Run some other process that eats a lot of CPU time!

I just ripped a 70 minute CD in 3 minutes 20 seconds. While the rip was running, I had another window running vorbisgain on a whole bunch of subdirectories located on an external USB hard drive. The vorbisgain process is running at about 100% on one core.

I think this tends to confirm that the problem is in the CPU speed scaling system. Maybe I should run Seti-At-Home any time I want to rip CDs???

Bill Gee

[RupertPupkin]

Originally Posted by CrazyCaver

If DMA were disabled on the optical drive, I would think that burning would also be slow.

Well there's one sure way to find out: use the hdparm command (from the hdparm package):

# hdparm -I /dev/sr0

/dev/sr0:

ATAPI CD-ROM, with removable media
        Model Number:       TSSTcorpCD/DVDW SH-S162A
        Serial Number:
        Firmware Revision:  TS01
Standards:
        Likely used CD-ROM ATAPI-1
Configuration:
        DRQ response: 50us.
        Packet size: 12 bytes
        cache/buffer size  = unknown
Capabilities:
        LBA, IORDY(can be disabled)
        DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns

As root you could enable DMA on <your_CDROM_device> like this:

# hdparm -d1 <your_CDROM_device>

[CrazyCaver]

Running the hdparm command on my system gives this result:

[root@main2 B]# hdparm -I /dev/cdrom

/dev/cdrom:

ATAPI CD-ROM, with removable media
        Model Number:       TSSTcorp CDDVDW SH-222AL                
        Serial Number:      R8JQ6GDB700016      
        Firmware Revision:  SB01    
Standards:
        Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 
Configuration:
        DRQ response: 50us.
        Packet size: 12 bytes
        cache/buffer size  = unknown
Capabilities:
        LBA, IORDY(can be disabled)
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns

I think this means that DMA is on for the optical drive.

This whole thing has taken yet another interesting twist ... Today I ripped a CD, and it worked like it should! I did not have any CPU-consuming process running. I have not rebooted the computer nor made any patches to it. This is like totally weird ... No wonder my AKA is "CrazyCaver"!

I guess all I can do is keep an eye on it.

Thanks for all the suggestions.

Bill Gee