Joe 'Zonker' Brockmeier ([EMAIL PROTECTED]) wrote: > Hmmm. If you're getting skips without any other system activity, > then it might be a problem with SCSI throughput...here's a section > from the cdda2wav README: > > Recommendations for higher throughput on Linux SCSI systems > =========================================================== > > Higher throughput will give better chances for non-interrupted > sampling. This should avoid typical interruption errors (cracklings > at buffer boundaries). > > 1. Increase SG_BIG_BUFF to (128*1024) in /usr/src/linux/include/scsi/sg.h > (and recompile your kernel and boot it :-). > NOTE: Some kernel configurations will lead to 'out of kernel memory' errors. > If you encounter this message regularly, better leave SG_BIG_BUFF at > 32768. > > 1a.There is a patch for multiple sg device access under Linux. It uses > up to 128 K buffer for each device. See here: > ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha/sg* > > 2. Ensure your harddisk has write cache enabled (For SCSI hard disks I > switched it on with the scsiinfo program from tsx-11.mit.edu), but > enable this only if it is correctly working ;-) > > This has boosted the throughput of cdda2wav considerably.
Actually I did RTFM (-; however this no longer seems to be the case
(at least with 2.2.18):
- this driver no longer uses a single SG_BIG_BUFF sized buffer
obtained at driver/module init time. Rather it tries to obtain a
SG_DEF_RESERVED_SIZE buffer when a fd is open()ed and frees it
at the corresponding release() (ie per fd). Actually the "buffer"
may be a collection of buffers if scatter-gather is being used.
I'll look into the disk cache. I'm wondering if there is anyway to
make cdda2wav check the newly created .wav against the data on the
disk to make sure they match? -M <count> might do that, but it would
be a PITA to have to figure the size of each track. Any other ideas?
TIA,
Ron
--
Email: <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
Home: <http://www.farrer.net/~rbf/>
pgpwftsEVA01W.pgp
Description: PGP signature
