Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke helmi 02 2000 - 16:17:32 EST
>My engine works the same way than yours and I have wondered if I should
>at all give the splitting to kernel. What is the different in reading
>1 seconds blocks or smaller blocks for 26 tracks simultaneously? Overhead
>in moving from thread to thread, and kernel space to user space?
Well, I sent my test program a while back, so you can see for
yourself. On my system, for example, reading 9MB in one chunk takes
about 0.6 seconds, but reading it in 24 chunks can take up to
1.6secs. Such numbers are next to useless without context to them,
however. Did the disk head move between the 24 read's, for example ?
>Maybe some combined audiocard/disk _driver_ could really push the limits
>of the hard disks.
Well, then we start moving away from Linux and towards some custom
audio platform. The new rawio stuff in 2.3 would allow you to have
almost complete control over disk i/o, but at the cost of having to
write a complete VFS compatible file system if you want any other
program to be able to read the data as a normal file.
Anyway, we don't need to push the bandwidth limits of hard disks -
they can easily do what we need them to do. Even with random seeking
and small block sizes (4K), I can get 40MB/sec out of my Ultra-2 SCSI
drives. Thats way more than we need for 24/24/96 (9MB/sec).
The problem is seek time, and thats not affected by the device driver
apart from its disk scheduling policy. Since in all cases the goals of
a disk driver are basically the same - reduce seeking, reduce seeking,
reduce seeking - its not clear to me that a dedicated driver would be
any different to the existing one. That is, however, assuming that the
existing driver (in my case, Doug Ledford's aic7xxx SCSI driver) is
doing the right thing for disk scheduling. There is good evidence that
it does a great job, especially with the new stuff in 2.3 (up to 50%
gain in throughput!).
>You could now try that fsync() trick for recorded (to disk) tracks.
>Or decrease the amount of memory when virtual memory system flush
>data to disk. I suggest to use fsync() for certain reasons.
fsync is a *bad* idea from my perspective. It circumvents the whole
purpose of the buffer cache, which is to provide optimal buffering of
data to/from the disk. Now I will be the first to admit that the
buffer cache doesn't always do the right thing, but believing that you
know when is the right time to call fsync (except at the end of a
recording) seems to assume too much.
If nothing else, use fdatasync, rather than fsync, so that the head
doesn't have to seek back/forward to update the inode metadata as well
as the actual disk data.
In general, memory during recording is not too much of a problem, in
that you can just buy more :) Alas, there are no good deals on reduced
seek times that I've seen!
--p
ps. sorry if i sometimes come across as an arrogant bastard. its just
my way of writing. apologies if it offends anyone.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST