Subject: Re: [linux-audio-dev] [Fwd: [patch]2.4.0-test6 "spinlock" preemption patch]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Sep 07 2000 - 21:10:31 EEST
>I agree that the seeks should be minimized, but IMHO the best way to achieve
>this is to let the userspace app read and write large blocks, and at some poin
>t
> increasing the read/write blocksize does not increase the throughput anymore.
>And I think this value lies around 256-512KB (ad PBD will agree on this).
yep. thats my experience. i run ardour with a 256kB block size, and
going larger has never improved performance of ardour or any
mini-benchmark that i've used.
>So a smart of stupid disk scheduling algorithm does not matter in that case.
>I think HDR applications should not rely too much on smart disk subsystems too
>much.
i agree with this entirely. when i started ardour, i was interested in
the possibility of something like streamfs. however, having
demonstrated that everything i wanted can be done with ext2fs, i am
more concerned to keep things simple for the user (and
developer!). that means using standard filesystems wherever possible,
unless a special one provides an order of magnitude improvement or so.
>Plus think about the fact that a good HDR app has to provide varispeed too
>(eg one track playing slower or faster than the other), thus all the
>interleaving at FS layer are worthless in that case (and perhaps it can
>even lead to lower performance compared to a plain FS)
more than this: with non-destructive editing (EDL-based playback, next
year's big project :), there is no reason to assume much continuity on
the disk at all. you could potentially be jumping all over the
place. i read some numbers from digidesign about this - i think they
require disk performance (seeking, really) capable of supporting 3
seek-requiring edits per second. once you start to deal with this, the
whole idea of the data being laid out "optimally" starts to look
pretty remote. juhana has mentioned an interesting (old) article that
suggests that its better to use a random layout of data in big blocks
for audio work.
--p
This archive was generated by hypermail 2b28 : Thu Sep 07 2000 - 22:18:58 EEST