From owner-freebsd-hackers Tue Nov 28 15:49:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA17561 for hackers-outgoing; Tue, 28 Nov 1995 15:49:05 -0800 Received: from tcsi.tcs.com (tcsi.tcs.com [137.134.41.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA17553 for ; Tue, 28 Nov 1995 15:48:58 -0800 Received: from phact.tcs.com (phact.tcs.com [137.134.41.99]) by tcsi.tcs.com (8.6.10/8.6.10) with ESMTP id PAA06132; Tue, 28 Nov 1995 15:45:33 -0800 Received: from cozumel.tcs.com (cozumel.tcs.com [137.134.104.12]) by phact.tcs.com (8.6.10/8.6.10) with ESMTP id PAA11017; Tue, 28 Nov 1995 15:45:32 -0800 From: Douglas Ambrisko Received: (ambrisko@localhost) by cozumel.tcs.com (8.6.10/8.6.10) id PAA09388; Tue, 28 Nov 1995 15:45:17 -0800 Message-Id: <199511282345.PAA09388@cozumel.tcs.com> Subject: Re: Anyone keen to help me get a Phillips CDD 521 Recorder working? To: dufault@hda.com (Peter Dufault) Date: Tue, 28 Nov 1995 15:45:16 -0800 (PST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.org In-Reply-To: <199511281252.HAA08317@hda.com> from "Peter Dufault" at Nov 28, 95 07:52:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2214 Sender: owner-hackers@FreeBSD.org Precedence: bulk Peter Dufault writes: | | > > | > > I'll checkout rtprio, and I'm sorry I don't have all the specifics | > > right now (you can probably find them at http://www.cdarchives.com) but | > > the Yamaha is a 4X writer with only 512k buffer. | > | > 4times, 6times -- what's the base for the comparision? | | The unit is a single speed CDROM at 150K/s. So this 4X driver is 600K/s, | so you have under a seconds data in the FIFO. Exactly why some people don't use this CD-R and others have troubles with it (but it is fast and cheap!). | (This makes more sense than the frame grabbers that I've seen advertised that | operate at "twice real time".) | | > The SCSI bus itself can transfer about 8 MBytes/s continuously (on a | > "standard" 8-bit controller, like the AHA-2940 or NCR 53c810). How | > close do these burners come to that value? | | They hopefully burst into their RAM buffers at this speed to give you the | latency you need to go read another chunk. Also where is the data coming from, I don't have 680MB free memory to cache the CD-R image to do the burn. So the data has to come from a hard drive attached to the SCSI bus. A lot of burners use a separate SCSI bus for the CD-R so it's doesn't have to worry about any other device holding the bus. Also people use AV disks to eliminate the problem of thermal recalibration. What about people with an ISA bus with X? In the future this shouldn't be as much of a problem since most CD-R's now, support large caches of atleast 2MB. In the MS-DOS/Windows world you can grab the CPU to just work on the burn. The CD-Studio caches the entire image on the units internally disk and then does the burn (which is nice because then you can down-load an image over a busy net). Doing a CD-R burn is possible (look at Linux, all the code has been done for some CD-R's) but ensuring a successful burn is not easy. All the caveats must be identified or there will be frustrated people trying to make CD's. Something that might be useful would be a test program to verify enough system throughput to do a reliable burn (and let's hope they are not doing make world and spinning 10 teapots under X waiting for their CD to burn). Doug A.