NO PROBLEM !
:-)
using a single thread approach ala Re-Wire ,
running all your RT software as plugin of one single host,
makes it easily possible to run dropout-free 3ms latency software.
(of course you need the lowlatency patches)
in your soft-synth + HD Recorder example:
the HD-recorder "re-wires" the softsynth output to his audio busses
, in fact running the soft-synth as a plugin of his RT thread.
And believe me, this approach let's you run even 10 RT (3ms latency)
applications simultaneously , since there is effectively only one
RT thread running.
The disk IO/GUI etc stuff is handled by lower-priority threads which
have no influence on the RT thread.
But that was I am trying to demonstrate is that you can run
5-6 SCHED_FIFO processes in parallel (without "re-wire" )
as standalone applications, all with 3-5ms latency. (droput-free).
A guy on the linux-kernel list, is actually testing multiple SCHED_FIFO
processes and reporting good results, but I want to get my own
benchmark results to be 100% sure.
I think that this can be done, although this increases scheduling overhead.
I will report testdata as soon I get some results.
(I will have to write a new stress application)
I think the Steinbergs Re-Wire technology is pretty nice, end even simple.
A simple separation of DSP stuff from GUI stuff in LADSPA (which is already
here), makes a "re-wire" implementation trivial.
Allow your application being run as a plugin , that's all :-)
Benno.
On Tue, 28 Mar 2000, David Slomin wrote:
> Paul Barton-Davis wrote:
> >
> > A) I doubt that you could run the above in real time with low enough
> > latency to make the synth playable from a MIDI controller. Although
> > modern processors are fast, there are limits :)
>
> That's not a good sign. At least for me, a soft-synth is utterly
> useless if it cannot be recorded while being played from a MIDI
> controller in realtime. Does this mean that every soft-synth and
> soft-sampler must double as a single-track HD recorder?
>
> "realtime" ,--> audio output
> MIDI ------> soft-synth ---<
> input `--> disc
>
> That's definitely a bare minimum though, unusable for more than
> the most trivial hobbiest work. A more realistic minimum would use
> a standalone multitrack audio editor with a decent interface (not
> a minimalistic HD recorder tacked onto the soft-synth).
>
> "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.
>
> Inserting effects into the flowgraph is something that I
> personally don't have a need for during the realtime recording
> stage (I can do it offline later), but other people on the list
> have asserted that they can't live without it. That gives us:
>
> "realtime"
> MIDI ----> soft-synth --. mix to
> input ) ,---> audio output
> ,-- effects <--' (
> / `--------------.
> \ \
> \ more /
> \ multitrack ,--> effects --'
> >-----> audio ----<
> existing / editor `--> new track
> audio ----' to disc
> tracks
>
> I agree that this is starting to look scary, but it is indeed
> a minimum requirement for many people. If the only way to do
> this on a current-generation processor is to have all of the
> pieces run in a single process, then that single process will
> no longer have the design problems of an application; it will
> be a miniature operating system. It will need careful
> coordination not only at the level of flow routing, but also
> in presentation of the UI, not to mention code
> compartmentalization (so that different developers can work on
> different pieces). Designing this mini-OS is a task that I
> doubt anyone can do in a way that all users and developers
> will agree upon.
>
> 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.
>
> Div.
>
> --
> David Slomin, Engineer mailto:[EMAIL PROTECTED]
> AltaVista Business Solutions http://solutions.altavista.com/
> RFC 822 plaintext email strongly preferred except for attachments
