[Libcdio-devel] libcdio vs. OSX, exclusive access vs. non-exclusive access.

[R. Bernstein]

Getting a CD-ROM driver for OSX has been a real hassle. In fact more
of a hassle than Microsoft Windows which is really saying something.

Some of the following info I may have communicated to individuals
privately. I wanted however to summarize what's known or not known for
the broader libcdio community.

On OSX there are currently two cdparanoia programs that I am aware
of. One by Tobias Sargeant which can be found here:
  http://www.livejournal.com/users/strangehours/9698.html

and another by Scott Wood which can be found here:
  http://www.buserror.net/cdparanoia/

Actually I was trying to find a contact for Tobias when I came across
Scott's cdparanoia port. One of the interesting things about this
latter port is that it has a way to issue a SCSI-MMC command. This has
been long-sought since it opens the way to do a lot more than can be
done currently by libcdio's OSX driver.

I contacted Scott and asked for his okay to adapt his code. He emailed
an okay and so right now you find the get_scsi() inside
libcdio/lib/driver/_cdio_osx.c.

It however is not working and has been disabled. 

What I later learned is that in order to issues a SCSI-MMC command one
needs exclusive CD-ROM access; nothing else can have access to the
CD-ROM beforehand. So in Scott's cdparanoia you have to issue the
appropriate "disktool" command to unmount the CD-ROM, because OSX just
likes to have it mounted. And when the cdparaonia program quits, the
CD-ROM is reaccessed with permissions that might be different than
what they were set previously. Scott says he has a script to run his
cdparanoia which issues the disktool commmand, but I think he
acknowledges that this is not really an ideal situation.

Steve Schultz informs me that some of the commercial CD-burning
programs for OSX are able to wrest control of the CD. However, right
now it's not generally known how to do this.

Given this, probably for now libcdio will stay with non-exclusive
CD-ROM access.

But when Scott graciously look over my code in _cdio_osx.c, he pointed
up a weirdness and general difference in the way things are done in
that code:

   It seems to be using a rather different way of finding the relevant
   io_service_t; are you sure that whatever it's returning has the
   SCSITaskDeviceCategory property with a value of
   SCSITaskAuthoringDevice?  There are several different nodes in the
   device tree that correspond to a single drive, and only one of them
   has this property.  You can't get at the MMC interface without it.

Okay. No doubt this suggests one reason the current get_scsi() routine
won't work. Scott also adds: 

  Once it gets the BSD matching node, it traverses parents until it
  finds IOCDMedia or IODVDMedia.  The node that is needed is
  IODVDServices (or IOCDServices if the drive doesn't do DVD).  Adding
  another loop to go farther back should do it.

Since I don't have an OSX box, it's hard for me to develop on it, let
alone reap the benefits of the code I write. I relay the above
information in case others are interested in persuing.

And this may be related to another bug found in the libcdio release
0.71 and probably the current CVS. libcdio is used as an alternative
CD-DA plugin for videolan's media player, vlc. Derk-Jan Hartman found
he could no longer read audio sectors after replacing his CDRW drive
with a DVD/CD-ROM drive (LITEON DVD-ROM LTD-165H).

I asked him to run cd-info (from his libcdio 0.71) and he gets this:

  ++ WARN: IORegistryEntryCreateCFProperties: 0x10000003
  Disc mode is listed as: Error in getting information
  ++ WARN: IORegistryEntryCreateCFProperties: 0x10000003
  cd-info: Can't get first track number. I give up.

To which he reports: 

  OK. this particular error code means the MachKernel port to a device
  went dead (in this case the io_service_t service).  I added some
  debugging, but service != 0 So i remember spotting something about
  caching services and their names somewhere in this code and lot's of
  notations of 'hacky' in those areas.

  so i was thinking that maybe the service became invalid and the cache 
  isn't working in this case. 

Again I copy this because it may be of interest to an OSX hacker.

Finally, for completeness I should also mention that Justin F. Hallett
has been trying to verify that cd-paranoia works on OSX. (Sorry
Justin, I meant to mention you effort in the previous post on
cdparanoia). Currently he's getting an error in cd-paranoia where the
2nd track's LSN is clobbered with a 0 even though other programs
work. This problem seems more like a memory-clobbering problem similar
to (but probably different from) my Solaris simulated-jitter
problem. I don't think it is related to any of the other problems
mentioned above.