>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. >3) Good/correct IDE drivers for the chipset. With Linux at least, you have >pretty good control over this: just make sure you build your kernel with the >IDE chipset driver compiled into the kernel statically [it needs to activate >prior to the mounting of /]. How to know what drivers there already are? How to know if the driver in use is not the correct one? Can the default IDE drivers work for a IDE controller with possible limitations? That is, the problem with IDE driver could go unnoticed without an expert help. How to drop the speed of the IDE? Reliability vs. speed. >If not, you can set them up with: > >hdparm -c1 -u1 -d1 -m16 /dev/hda I made the change, but the speed stayed the same: % hdparm -t /dev/hda: Timing buffered disk reads: 64 MB in 2.23 seconds = 28.70 MB/sec Regards, Juhana
