Juhana Sadeharju wrote: >>From: Malcolm Baldridge <linux-audio@xxxxxxxxx> >>Subject: Re: [linux-audio-user] Ardour, Jack, and 2.6 kernels + XRuns >> with the Audiophile 24/96 M-Audio >> >>1) You can't use more than one drive per IDE channel. > > [ ... ] > >>It's VERY bad on performance to mix very slow devices (such as CD-ROMs) >>with fast ones: they hold a lock on the bus during all operations, > > > I recently removed CD-ROM device completely. I ended up doing that > because I got disk errors. The disks are perfectly ok, however. > Some example symptoms were: > -When the CD-ROM device slided in the disk, Alsa audio play was > interrupted for 7 seconds > -File copy sometimes made errors -- such as the highest bit of one > byte of 300 MB file turned from 0 to 1 > -File was temporarily corrupted -- error stayed at the same place, > no matter how many times the file was verified; after the boot, > the file was again ok; I made sure the caches were emptied, and so, > it looks like a certain bit pattern or certain address caused the > change in data > > I'm still testing and waiting for errors to happen. > > This problem has driven me to verify that files are copied ok, > that the created tar.bz2 packages are ok (both the tar.bz2 file > and its content). I also have set Emacs to make the numbered backup > copies and make them by moving (not by copying). Backups, flac, mp3 > and ogg codings need to be verified too. > > The point is this: how you would know about the rare bit changes > if you never verify the files? > > In audio work such a bit changes can go unnoticed. How many of you > verify, e.g., that a simple edit to a file did not made a bit error? > I'm sure that no one verifies. Use of a dither makes the detection > quite hard. I would be interested in a filesystem that computed checksums in the background every time a file was copied and reperformed bad copies, but this sounds like it could be a substantial hit on performance. I wonder if we'll ever see something like this, or if something already exists even. Chris
