Subject: Re: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Benno Senoner (sbenno_AT_gardena.net)
Date: to helmi 03 2000 - 07:45:03 EST
On Wed, 02 Feb 2000, Paul Barton-Davis wrote:
>
> 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).
Hi folks, I watched the multitrack playback discussion,
as far as I can tell you,
using multiple threads to read the track could not be the best idea.
In my multitrack playback experiments, I got the best results using:
- mmap() / munmap() instead of read()
(read() seems to read ahead too much, therefore wasting some of the disk
bandwidth
- using one single thread to read all tracks in sequence
- using large buffers at least 1MB/track , otherwise you get not enough
reliability
- using a single thread you schedule readings by "most empty" playback buffer,
which allows you to easily implement varispeed.
( varispeed is easy to implement in a multithreaded context too, but the
problem is that in that case streams playing at higher pitch (=playback
frequency) have to be "prioritized" in order to improve reliability.
I am sceptical about the fact the the disk driver always serializes disk access
in the best possible manner.There are simply too much idiotic cases where
the logic of the disk driver doesn't figure out well the access patterns of
certain applications.
>
> 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
yes, reduce seeking , but the driver has to give up some seeking
optimization in exchange of a lower disk access latency.
> 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!).
>
>
> 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.
I agree, during writes you should call fdatasync() every 0.3sec - 2sec,
in order to avoid a large disk flush (on bigmem boxes) which could stall
other operations (disk reads for the playback) and cause dropouts.
>
> 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
>
I will do some testing with my HD playback code to simulate 24track @ 96KHz x
32bit.
My box here is a Celeron 366 with a 18GB 7200rpm IBM EIDE UDMA disk,
which does about 13.5MB/sec when writing a large file to the disk.
( 16MB/sec when reading)
Paul, are you requiring a separate disk for the audio tracks ?
I guess yes, because I tested multitrack playback on a single disk box,
and you if you fire up a large app like netscape, or do some disk I/O,
after a few secs the HDR application is unable to keep the buffers filled,
which results in a buffer overrun. (=dropout).
But I think the same applies to Windows or Mac since these OSes do not run
a guaranteed bandwidth I/O disk subsystem (which has to waste part of the
bandwidth in order to guarantee disk latencies and throughput (see old
discussion on linux-kernel)).
Anyway a disk doesn't cost a fortune anymore, and if you want you can
easily use multiple disks and spread the tracks across disks giving you
a bigger bandwidth and seek performance.
Benno.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST