[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Audio CDs on Titanium G4 Powerbook



I dont know if anyone ever followed up to some questions in late april
about how to get audio cd support working on the TiBook. I've done it,
here's what i had to do:

I posted something like this over on the linuxppc-user list at
linuxppc.org, but here is an update.

1) your kernel must be configured with generic scsi support and 
   ide-scsi support.

2) you must pass the argument "hdc=scsi" to the kernel on boot to make
   the ide-scsi package sense the drive and install a driver for
   it. i'm not sure how it works if you've compiled ide-scsi as a module,
   maybe you can insmod it with this argument (?). if your
   dvdrom/cdrom shows up as a different hd (a,b,d, whatever; check
   dmesg), you need to use that name in the kernel argument.

3) you should now have /dev/scd0, /dev/sda, and /dev/sg0. in my case
   /dev/sg0 was symlinked to /dev/sda. i discovered all of these by
   running "cdparanoia -vsQ".

4) grip -d /dev/scd0 should work, if you have grip installed. i havent
   tried any other front ends. 

5) as for xmms and playing CDs, read the issues below

issues:

'eject' doesnt work anymore. to eject the disc, i need to use
cdrecord: "sudo cdrecord dev=0,0,0 -eject" maybe if you adjust the
permissions on someof the devices this will not need to be done as root.

there are endianness issues in general. you might have to experiment
with the byte swapping features in cdparanoia, cdda2wav, lame,
etc. related to this, audio cd reader 0.9 against xmms 1.2.3 produces
white noise, but the spectrum display is correct (!) i cant tell for
sure where along the line the bytes are getting swapped; when cdrecord
ejects the disk it seems to think the driver is swapping bytes. i
hacked audio cd reader to swap the bytes it returns to xmms and that
sounds OK. i think the right solution here is to convince the driver
not to swap bytes, but i havent figured that out yet.

also, it appears that cdparanoia is not necessary for this drive,
since it can apparently produce clean audio, which means that all of
the 'paranoia' in cdparanoia is not needed. this would imply that
cdda2wav is a fine choice for ripping, given that cdparanoia is such a
resource hog. i was using cdda2wav until a couple of days ago when one
of my CDs was producing mp3s of white noise. reading the source for
cdda2wav, it looks like the endianness of the data coming off the
drive is guessed by analyzing the data. apparently sometimes this
fails. i dont see any ioctls() for the cdrom driver to swap bytes or
to report the endianness, so i guess that might be the only way to tell.

cdparanoia doesnt seem to have any such problems. unfortunately even
with all of it's paranoia checking turned off it still hogs resources
pretty badly (mouse jumps all over the place, etc.)

rob







Reply to: