Subject: Re: [linux-audio-dev] design question for HDR
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Apr 03 2000 - 21:15:24 EEST
PREAMBLE: I am fairly convinced that there is a design error on my
part, since I can get adequate sustained disk i/o rates even when done
with random seeks in between each 64K read.
Anyway, until I find it ....
>On the "just use enough memory side" VST uses truly colossal buffers - I
>often set it to 256kb per track.
I've used 960kB per track. It doesn't help, it just delays the disaster.
>When you hit stop or move the transport there is a massive burst of disk
>activity as the buffers are pre-filled - perhaps it is this (overkill?) that
>allows it to keep up on average.
Yep, ardour does the same thing. But the basic problem is that we
can't keep up. I ran the numbers for Richard this morning:
playback data rate: 4.4MB/sec
1 seconds worth of data: 187kB
average time to do a random seek and then read 187kB: 28ms
time to do this for 24 tracks: 672ms
slack time per second: 328ms
slack time: 616msec
Sounds good. And often, it is.
However, all it takes is various O/S-driven stuff to cause the
seek+read time to be much longer (say, 70ms), and for this to happen
on several tracks, and boom, your slack time per second of audio data
is all used up. OK, you say, use a bigger buffer. That helps, but in
the end, if abnormally long seek+read behaviour keeps happening, it
will only delay the point at which the duration of insufficiently-fast
disk I/O causes an underrun.
>OTOH this does mean that a long looped section of replay gets a stutter when
>the loop wraps - accompanied by the same massive burst of disk activity.
No, you just do sensible read-ahead. Ardour doesn't do this yet - it
won't handle it until I add support for playback from a playlist, and
the format of that playlist needs to be integrated with at least one
non-destructive editor, probably snd.
>Another thought occurred - the possibility that the down-side of many
>threads (perhaps one per track - I'm sure VST uses the multiprocessing lib -
>which allows pre-emptive threads on MacOS) might be mitigated by an improved
>behaviour to blocking by IO.
I just use one thread. There is only one disk controller, and some
experiments I did some time ago suggested that having N threads each
"queue" 1 disk request didn't make the overall throughput any faster
than having one thread make N serial requests. The typical time
between the butler thread returning after some disk i/o completes and
it making a new disk i/o request is a few 10s of microseconds. Unless
the disk controller driver is able to do sensible reordering of the
disk i/o, it won't help to have them submitted sort-of-in-parallel,
and anyway, i'm already submitting them in a sensible way if you
assume I have a dedicated disk.
>I think that, maybe, I don't understand the behaviour that you want from
>your system - because large buffers is too obvious...
Its all about guaranteed disk access times, and Linux doesn't do much
to offer this.
--p
This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 21:10:56 EEST