Re: [linux-audio-dev] design question for HDR

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] design question for HDR
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Mon Apr 03 2000 - 20:47:33 EEST


On Mon, 03 Apr 2000, Iain Sandoe wrote:

>
> On the "just use enough memory side" VST uses truly colossal buffers - I
> often set it to 256kb per track.
> 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.
>
> 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 the loop shouldn't stutter, because the read-ahead algorithm, preloads
the data following a playlist.
You get the disk bursts because Cubase has to invalidate ALL buffers when you
move the transport bar.
Scheduled jumping because of non-destructive editing or looping doesn't cause
a relevant overhead, since for multitrack operation you have to seek anyway.

>
> 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.

The optimal strategy is to use one single thread which reads all tracks
sequentially , let's say 64kb-128kb at time.
Using multithreading kills disk performance because the OS can't perform
optimal scheduling.
If you have more than one disk, you should use one reading/writing thread
for each disk, in order to get maximum parallelization since I use blocking
read/write in my disk i/o code.

>
> How much seek optimisation does the Linux fs do?
> Is it possible to influence this from user space?

"schedule" the disk-seek manually as in my example above,
you will get best possible performance, because
firing up 10 threads trying to read many files simultaneously
ends up in a seeking nightmare.

>
> I think that, maybe, I don't understand the behaviour that you want from
> your system - because large buffers is too obvious...

large buffers + single threaded reader + refilling by "most empty" buffer
policy, delivers (IMHO) best possible performance.

>
> Iain.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Apr 03 2000 - 22:19:01 EEST