I thought EsoundD just provided shared access to audio hardware by mixing.
Does it do more?
The future heart of the MN system is the 'mnd' process (MN Daemon). This
provides facilities to manipulate and run networks of unit generators.
Communication is socket-based at the moment (although I'm finding this a
little clunkier than I'd expected - it will be easy enough to drop
something else in). The interface is very simple and protects the client
program or GUI from the horrors of manipulating unit generators and flow
graphs. This lets you route audio between unit generators, but not between
applications.
If interested, I can send people a prototype 'mnd' binary and C++ and Java
wrapper classes for the socket communication. I've not released it as the
interface needs quite a few extensions and I've not finished the Java GUI
yet (I've actually done some work on this today). I probably ought to
mention that the source for the daemon is not available at this time
although the GUI code could be if anyone were interested.
So far we seem to have the following interface points:
(1) plugin <-> app (unit generator code sharing - LADSPA and VST plugins do
this)
(2) app <-> GUI (control/config/flow graph interface. No common standard -
yet?)
(3) app <-> app, device etc (live streaming - ReWire does this, Linux
doesn't yet)
These interfaces don't have to be so separate and this isn't the only way
to provide them. (3) could be achieved by presenting one process to another
through some kind of plugin wrapper, producing a somewhat twisted form of
(1). (2) could be achieved by direct communication between plugin and GUI
although this has problems as Maurizio points out.
-- Richard
-----Original Message-----
From: Maurizio DE CECCO [SMTP:[EMAIL PROTECTED]]
Sent: Friday, March 31, 2000 2:45 PM
To: Paul Barton-Davis
Cc: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] audio application mixing/routing arch
Paul Barton-Davis <[EMAIL PROTECTED]> writes:
> Connecting them together: now, how does a standard, daemon-style host
> connect them together ? You'd have to have a (G)UI that allowed the user
> to specify the routing, then relay this information to the
> daemon. What you're describing now sounds more like a replacement for
> esd.
Please don't !!!!
The daemon (or whatever) should offer an API for making the connections;
the API can be a library communicating with the daemon with some IPC
technique.
The daemon should not be linked with any code making direct user
interaction;
(think for a moment to a embedded Linux kernel running on a real synth
:->).
IMHO, plugin that have a direct UI (i.e. a UI running on the same process
of the daemon)
are not a good idea on a Linux based architecture; think of having a plugin
made
with a Kde interface running on a GNOME system ...
Leave the DSP code and the UI interface code separate, otherwise the whole
thing will need to be redone tens and tens of time ...
--
Maurizio De Cecco
MandrakeSoft http://www.mandrakesoft.com/
