Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: David Slomin (david.slomin_AT_av.com)
Date: Thu Mar 30 2000 - 00:36:13 EEST
Paul Barton-Davis wrote:
>
> If the soft-synth is not multithreaded, then disk i/o will lead to an
> inability to meet the latency demands of real time performance. So the
> first requirement is: a thread doing real time audio synthesis never
> blocks for anything except the audio hardware. Thats already a rather
> complex design requirement for many people.
Threads, although they do have their difficulties, are very pervasive
in modern programming. They are required (or are the simplest and
most common of several solutions) for proper interactive UI design,
are the popular method of choice for writing servers, etc. I don't
think that they'll scare off too many people.
> > "realtime"
> > MIDI ----> soft-synth --. mix to
> > input \ multitrack ,--> audio output
> > >---> audio ---<
> > existing / editor `--> new track
> > audio ----' to disc
> > tracks
> >
> >I find it very hard to believe that this kind of setup would
> >necessarily result in unusable amounts of latency. It's such
> >a fundamental thing that without it, there wouldn't be any
> >concept of using computers in a music studio.
>
> Huh ? There are all kinds of uses of them that don't involve anything
> like the above setup. Non-linear real time editing, HDR, realtime
> synthesis, non-realtime synthesis, mixdown, FX processing ... these
> are all useful functions for computers in a studio, and none of them
> have to involve the setup you describe above.
I apologize. There are indeed many studio activities that can be
done effectively in a single process, such as pure HDR. I wasn't
intending to refer to anything other than realtime stuff; after
all, latency is not an issue when you're doing mixdown or working
offline.
> In the chain above, there are at least 2 processes (the synth and the
> editor), possibly three or four or five depending on how one were to
> decompose the tasks.
I wasn't trying to invent an impractical case; certainly it's not
hard to dream up things that would make a Cray sweat. I was only
referring to the two-process version, which I hope is not
unreasonable.
> >Thus I really hope that it is possible to run a nontrivial
> >flowgraph in separate processes; otherwise we're not ever
> >going to get anywhere.
>
> Sure we are. VST and TDM and the rest don't require separate
> processes; I don't think that you could argue that ProTools or Cubase
> "hasn't got anywhere". They use a plugin model instead, which is
> vastly more efficient than threads, let alone processes.
I started writing a rather bitter response to this along the lines
of saying: "Cubase is so self-contained that it is a complete
operating system. As such, it has several strengths in the latency
department, but I'm not willing to give up all the benefits of a
general purpose operating system like Linux."
However, when I thought about it for a moment, I realized that most
of my complaints were in the user interface department. I probably
could live with the computational engine of the soft-synth running
in the same process as the computational engine of the HDR, as long
as the UI's were in separate processes. Of course this means that
some IPC will still be necessary (counting the host, there are now
three processes instead of two!), but it is now out of the critical
path. Since this seems to be what folks here are aiming for, I'm no
longer so disgusted by the proposed LADSPA approach.
Along these lines, would it not make more sense to talk about a
LADSPA daemon with no interface being the host? I'm confused when
people say "my HDR will be a host", "my soft-synth will be a host",
etc. Shouldn't they all be clients? At the very least, they're
conceptually peers, so one can't be hosted by the other.
Div.
This archive was generated by hypermail 2b28 : Thu Mar 30 2000 - 01:51:55 EEST