[lug] DVD Burner Recommendations

[David Morris]

On Mon, Dec 29, 2003 at 03:03:46PM -0700, John Hernandez wrote:
> Two questions inline...
> 
> David Morris wrote:
> >
> >Two possibilities here for what is going on here:
> >
> >First, the DVD drive might not be acting as a bus-master for
> >the transfer, which means data is transfered through the CPU
> >instead of directly to RAM/Disk.  That can easily suck up
> >all your resources, and is why I personally use *only* SCSI
> >CD/DVD writers.  Most IDE CD/DVD writers have this
> >capability now, but not all.
> >
> 
> Can you explain the method used under Linux to determine if a specific 
> drive has the bus-master capability?  And if the capability is there but 
> turned off, how to enable it?

Now, I'm venturing into areas I'm a little hazy (and rusty)
on, so please correct me anyone who knows the details
better.

The basic theory of a DMA (direct memory access) is that a
device other than the CPU can control data transfers.  This
device is called a bus-master.  SCSI devices *always* use
this method of data transfer, though drivers & software
don't necissarily use it efficiently (more on this below).
IDE by itself doesn't use DMA for data tranfers. Protocols
sitting on top of IDE (such as "UltraDMA" you see often now)
add this capability on, but not all devices use this added
capability.

That said, I *believe* that the determination to use DMA is
mostly done at the hardware level, possibly with some help
from the kernel-level drivers.

> >The second possibility is simply poorly written software
> >that doesn't let bus-mastering do what it does best (reduce
> >the resource cost of data transfer).  Not many people (and
> >even fewer companies) care about writing software the
> >"right" way... they just want to get a finished product
> >regardless of the quality.  
> >
> 
> Are you aware of any such limitations with common OSS
> DVD-Video player applications like Xine, mplayer, Ogle?

So how does this fit into your specific application?

Software always has the choice of how it accesses memory
(Even a DVD read is just a memory address it accesses).
Sometimes it is convenient to read memory in small chunks.
Other times you want to move a huge portion of data at a
time.  What some people do in writing software is fall back
on what they know how to do easily (move small chucnks of
data round) and apply that in the wrong place (moving large
chunks of data around).

Most of the time this doesn't pose much of a problem, but
consider your case of reading several gigabytes of data from
a DVD.  If the software you use is reading byte-by-byte to
transfer gigabytes of data, you will kill your system no
matter how good it is.  

Now, lets say you have just a few small snags along the
line.  No one piece of software, driver, or hardware is
designed really badly, but a few steps along the way have
problems when you get up to handling something the size of a
DVD.  These types of problems will stack up exponentially
and lead to using all your system resources.  Especially in
the case of a DVD read where you are moving data around at
nearly the system limits anyways (writes by the nature of
DVD writing technology can never occur this fast).

I don't use DVDs myself, but I read, write, and copy CDs
constantly.  I always use `dd` for this purpose myself.  dd
is a small program that accesses a device directly (e.g.
/dev/scd0) to pull data from in and place it into a file.
I've never had any problems with system performance during
this, but then I also ensure I build my systems with such
capabilities in mind (for instance, all have a SCSI card,
and all CD/DVD devices are Plextor SCSI, all Hard disks are
IBM or Seagate SCSI, etc.).

As I said, I could be completely off-base here, so correct
me anywhere I'm off if anyone is more familiar with the
process.  Its been awhile since I dug into the workings of
devices at this level.

--David