Re: [linux-audio-dev] audio application mixing/routing arch

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

Subject: Re: [linux-audio-dev] audio application mixing/routing arch
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Mar 29 2000 - 00:52:18 EEST


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:david.slomin_AT_av.com
> AltaVista Business Solutions http://solutions.altavista.com/
> RFC 822 plaintext email strongly preferred except for attachments


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

This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 02:33:14 EEST