[Protux-devel] Re: MAD-0.0.2.cc

[Luciano Domenico Giordana]

ok, I confess I just cannot read the code now, I am finishing that
damn project, things are messy here.. But I think it is a very good
apprach and pre-coding. I have to understand your ideais, but
meanwhile, I will shortly explain what I have in mind from MAD, so you
can make a counterpoint (facing them... you know.. B.E.), and then we
can discuss it better..

--- MAD (Mustux Audio Server - Draft (written in a rush..)

MAD : a singleton class to provider online mixing (network transparent)

THE THING WORKING WOULD LOOK LIKE THIS :

MAD have 2 things : Audio Hardware buses (Hardware side) and (Logical
Buses) (Clients side)

MAD can map from logical to hardware buses (hard buses0. This way,
user has virtually infinite buses (soft buses)

Once hardware changes, user just remap "Hardware side".. logical
connections keep the same (Unless he wants to take benefit from new
hardware, of course)


An example of mapping :

Hardware side has 5 Hard buses : 4 mono and 1 stereo

the stereo is labeled "Preview bus , other 4 are labeled "drums",
"instruments", "voice" , "other"


Soft buses : 10 , 1 - cymbas, 2 - snares, 3 - other drums, 4- guitar,
5 - female voice...
and so on...

1 is hard mapped to HardBus 1, 2 is mapped to HardBus 1, and so on...

Hardbus 5 (the stereo) receives a mix from all other buses (even if
the signal have to be copied)

Note : this is what GISS does , (the software I still have to make public)

This process is called "Application Signal Routing". From the
perspective of an application, tracks or group of tracks are assigned
to soft buses, never to hard.
Applications does not even know  there are hard buses. It just dont
care. alsto, for all purposes, all audio is 32bits, and the sample
rate is a project-wide definition.

Also,The soft map can be copied to another linux machine running MAD,
so projects can be previewed logicall in any Mustux station.





NOW THE ARCHITETURE:


The BusFeeder thread : A single thread that keeps all audio hardware
buses open and "feedable". This is the BusFeeder

BusFeeder sends EQUAL CHUCKS OF DATA  to all hard buses iddentically
and CONTINUALLY in a blocked way. That should garantee smotheness.

This data (the one sent to hard buses) comes from "Collectors". Each
collection is nothing more than a logical pipe. Clients send data to
collectors (when transfering to soft buses) and the data is mixed in a
sincronized way, over the "current position"

It doesnt matter from where and when the data came (more on this
later), there will be a "cursor" showing pointing to the sample which
is being transferred to BusFeeder (busfeeder updates this cursor).

since collectors "next-sample-to-send-hard-bus" are updated and
manipulatd by a single thread (BusFeeder), they can be separated
threads.

Colectors works like valves that receiving requests from clients.
Primarly, I think they could be implemented as unix pipes. For network
transparency, they could be using RPC or corba. Anyway, this is
implementation. The important thing here is that they must act like
several "ports" of a "server".



This is a minimum explanation for what I have in mind. Please, face
this with your ideas and pre-code, and save for future discussions.

Thanks











On Fri, 23 Jul 2004 13:51:24 -0300, Luciano Domenico Giordana
<address@hidden> wrote:
> pleasem rename to Mad-0.0x.cc.RTF because I just cant open it
> normally. When renaming to rtf, things become fine
> 
> 
> 
> 
> On Fri, 23 Jul 2004 16:38:12 +0200 (CEST), Remon Sijrier
> <address@hidden> wrote:
> > > I dont think audio users even know what is "period"... dont mix
> > > Linux-power-geek-audio users with standard audio producers.. they
> > > badly knows what latency is  ... hehe
> > >
> > > fps is a more natural concept. As long as it is transparent to the
> > > application, there is no problem in keeping it like this...
> >
> > Ah OK.
> >
> > Because my brain didn't stop working on (like) MAD I've written down my
> > latest thoughts, hopefully you can get a clue about it ;-)
> >
> > Greetings,
> >
> > Remon
> >
> >
> 
> 
> --
> Luciano Domenico Giordana
> Software Engineer - Project Protux : http://www.nongnu.org/protux
> 


-- 
Luciano Domenico Giordana
Software Engineer - Project Protux : http://www.nongnu.org/protux